Does Gramps provide any database encryption. I checked the docs a little and found out Gramps uses BerkeleyDB and BSDDB3 set of APIs to communicate with it. While Berkeley itself supports encryption Supporting Encryption, I do not see the support of this method in BSDDB3 Berkeley DB: C Interface by Function/Structure, so I assume the answer is no. Is there any way Gramps protects our data from unauthorized access? The idea is to prevent reading the database by anybody without password with or without Gramps, i.e. including external tools.
Why do you want to encrypt the Gramps database?
Gramps data is stored on the PC, where you run Gramps, so if the PC is well protected then the Gramps data is also protected.
I’m a bit security concerned so besides using strong password, I also use OS managed disk encryption. This means that if someone should be able to remove the harddisk, the content will not be readable.
To store database on public clouds (OneDrive, Google Drive, MEGA, Dropbox, etc) for syncing. I don’t trust anybody, so I want to be sure my database won’t get into the bad hands if my cloud is compromised. And if it gets, I want to be sure they won’t be able to read it.
Gramps data is stored on the PC, where you run Gramps, so if the PC is well protected then the Gramps data is also protected.
For synchronization. When you sync smth, you cannot limit yourself only to your PC, you need to copy it through the public storage and public communication channels, that are not always protected.
what does this mean? I’m not familiar with Gramps development roadmap, so I don’t get your point. Berkeley is outdated? What is the default DB backend then?
SQLite is not a backend, it’s an embedded database.
If you want to run Gramps as a client-server setup, it gets much more complicated. I agree that a client-server configuration gives much more flexibility and growth possibilities, but I think very few Gramps users needs this.
What do you mean by “all types of backends”? Do you need document stores (Mongodb), triple-stores (RDF), partioned or sharded databases, graph databases or maybe hierarchical databases like IMS?
What do you mean by “all types of backends”? Do you need document stores (Mongodb), triple-stores (RDF), partioned or sharded databases, graph databases or maybe hierarchical databases like IMS?
I’m still learning Gramps, so I cannot confidently answer your question. My understanding from other folks’ posts in this thread, that one can use any Database for storing tree information in Gramps. And I didn’t know we can run Gramps in client-server setup.
I do not possess technical knowledge of Gramps to properly answer, sorry. Let me ask it simple: does gramps encrypt the information regardless of how it is stored (SQL database, No-SQL database, flat file or whatever)?
As I user I don’t care about how it is stored, but I want encryption.
If you use a PostgreSQL backend, then encryption becomes a database administration task. This should be possible with the current version of Gramps.
SQLite doesn’t support encryption by default, but there are extensions available. It should be quite easy to write a database plugin that uses the SQLCipher extension to encrypt a database, but we have no current plans to do so.
You simply do not store an active transactional database on any cloud‑sync service. Period.
If you need synchronization, you use the Postgresql database, or you do it by exporting and importing XML (or GEDCOM) files — not by placing the live SQL database inside a synced folder. A transactional SQLite database will inevitably conflict with how cloud services handle file syncing. They create partial copies, temporary files, and version conflicts, which leads to:
locked SQLite files
incomplete writes
sync‑delay overwrites
and ultimately corrupted database files
This is why people end up with dozens or even thousands of broken SQLite versions, where the data they thought was saved is actually trapped inside a corrupted sync‑error copy.
Cloud sync works great for documents. It does not work for active databases.
And if you need security, you can always encrypt the exported GEDCOM, XML, or whatever file format you use — at the file level, where encryption actually works reliably.
And if you need security, you can always encrypt the exported GEDCOM, XML, or whatever file format you use — at the file level, where encryption actually works reliably.
Ok, I got your point and I agree. However GEDCOM is not a database format, it’s an export format which only works for one time exports and migrations, not as a backend. I need encryption both at rest and in-transit. Maintaining GEDCOM encryption for export makes no sense if the database itself is not protected.
One small question: you are saying Gramps supports SQLite and Postgres as a backend. How to determine which backend my installation uses? I use Debian Linux version from snap, and Windows portable version on USB.
You don’t need an encrypted Gramps SQLite database, because the SQLite file should only ever exist on your local computer — and possibly on another trusted computer you own or control.
As I wrote earlier, you should never store an active SQLite database inside any cloud‑sync service. It will always end in some kind of chaos. Cloud sync tools are not designed for transactional databases, and sooner or later you will get:
locked SQLite files
partial or interrupted writes
sync‑conflict copies
and corrupted database files
There is only one scenario where semi‑simultaneous or shared use of a Gramps database works reliably, and this has been explained before on the forum and mailing list: If you truly need syncing and multi‑user access to a live database, you set up a PostgreSQL server and open the appropriate firewall ports so that other users — or yourself when remote — can connect to it. PostgreSQL is built for concurrent access. SQLite is not.
Encrypting files is also not difficult. You can simply ZIP the exported file with encryption, or use any proper file‑level encryption tool. That protects your data without risking database corruption.
Second point: There is no problem using GEDCOM or Gramps XML for “sync by files”. All you need is a tagging system for edited or changed data, export those changes, and then import them into the second local database. This avoids all the pitfalls of trying to sync a live transactional database through a cloud service.
Alternatively, you can use a tool like this: sqlite-sync-core · PyPI It allows SQLite‑to‑SQLite synchronization over LAN or VPN without involving cloud storage.
There are other SQLite sync tools as well, but most of them are designed for syncing with a PostgreSQL backend or SQLite Cloud rather than direct peer‑to‑peer sync.
Still no encryption here, other than whatever encryption you apply on the end‑to‑end connection.