Published
You press save. The database says "done". Can you put the kettle on, or is there still something waiting to reach disk?
Galactus DB gives you a choice about when a write gets its acknowledgement. That choice is called durability, and it is easier to understand when you think about what your application needs to hear before it carries on.
Sync: wait for the receipt
In sync mode, each commit waits for the transaction log to be flushed to
disk before the database acknowledges it. The application gets its answer
after that wait.
This is straightforward, but a disk flush takes time. If an application makes lots of tiny commits, it can spend a surprising amount of its day waiting for each receipt.
Group: share the trip to disk
group mode also waits for a disk flush before acknowledging a commit.
The useful difference is that concurrent commits can share the same flush.
Imagine colleagues putting their letters in the same post bag. Each letter still makes the trip; nobody needs to book a separate van. With several writers active, sharing the flush can make better use of the disk. With a single writer, there may be little to share.
Use it when acknowledged writes need to be durable and several parts of your application write at once.
Buffered: let the background work catch up
buffered mode acknowledges a commit once the log append reaches the
operating system's page cache. A background task syncs it to disk, with a
default interval of 50 ms.
The application can carry on sooner because it does not wait for that flush. The trade-off is real: a power failure or operating-system crash can lose recent acknowledged writes that have not reached disk. An ordinary database process restart is different, because the operating system still holds the written data.
This can suit data you can recreate, such as derived results or a graph rebuilt from another source. If an acknowledged write must survive a system failure, choose a mode that waits for the flush. The background interval is a scheduling setting, not a guaranteed maximum data-loss window.
Pick the promise your application needs
| Your application needs | A mode to consider |
|---|---|
| Each commit to wait for its own disk flush | sync |
| Durable acknowledgements with concurrent writers sharing flushes | group |
| Earlier acknowledgements, accepting the risk to recent unsynced writes | buffered |
Set the mode in your database container's environment:
GDB_DURABILITY=group
Galactus defaults to buffered. If you choose that mode, the optional
GDB_SYNC_INTERVAL_MS setting controls the background sync interval; leaving
it unset uses the default. Changing the durability mode does not clear other
explicit settings. Restart or recreate the container with the updated
configuration for it to take effect.
Use a persistent data directory whichever mode you choose. The Docker guide covers the container setup, and the configuration guide lists the settings.
Give each commit something useful to do
Batching helps in every mode. If you are importing a catalogue, putting a sensible batch of records in each transaction avoids asking the database to make a separate trip to disk for every item.
Keep batches manageable: a larger transaction also takes longer, holds more work in memory and has more to roll back if it fails. Choose a batch size that fits the job rather than trying to squeeze the entire import into one heroic commit.
For the comparison scores, the Galactus and Neo4j article shows buffered and group results side by side, so you can compare speed alongside the promise made to your application.