Launch Week Day 2: Embedded Replicas go GA with Production friendly upgrades

We previously announced a unique way to deal with your databases: Embedded Replicas.

Database replication is nothing new, but Embedded Replicas allow you to replicate the data deep down to your application, and then access it with microsecond latency.

We've been actively listening to feedback about how people expected to use Embedded Replicas, and today we are announcing that Embedded Replicas are going GA alongside three new exciting features for Embedded Replicas that will make it more usable in production scenarios.

#1. Periodic Sync

With the new Turso drivers, there is no longer the need to call the sync() function, and data is kept up to date periodically. Users who want the extra level of control will still have the option of calling sync() manually.

When creating a new client, you can now specify a sync interval:

import { createClient } from '@libsql/client';

const client = createClient({
  url: 'file:path/to/db-file.db',
  authToken: '...',
  syncUrl: '...',
  syncInterval: 60,
});

#2. Read your writes

Embedded Replicas also will guarantee read-your-writes semantics. What that means in practice is that after a write returns successfully, the replica that initiated the write will always be able to see the new data right away, even if it never calls sync().

Other replicas will see the new data when they call sync(), or at the next sync period, if Periodic Sync is used.

#3. Encryption at rest

Embedded Replicas can also now be encrypted at rest.

To use this feature, just specify an encryption key when creating the client:

import { createClient } from '@libsql/client';

const db = createClient({
  url: 'file:encrypted.db',
  encryptionKey: process.env.ENCRYPTION_KEY,
});

#How much does it cost?

Our community response was clear: nobody wants to be charged for reads done in an embedded replica. It's your resource after all!

Now that Embedded Replicas are GA, we're introducing a simple new plan allowance called bytes synced. That means only the amount of data that is transferred to keep the embedded replicas in sync will be tracked and count against your plan.

Note that every call to sync() transfers some data, even if there is nothing to synchronize. Make sure to adjust your periodic sync interval accordingly: fresher data will cost more, while more relaxed conditions will be cheaper to operate.

While reads done on an Embedded Replica are free, rows written to the main database still normally count against your quota. Also, keep in mind that some write operations may involve reads as well, like deletes and updates with a WHERE clause.

You can read more about Bytes Synced, and specific plan allowances on our pricing page.

#Embedded Replicas are ready for Production

You can now achieve Zero Latency reads with embedded replicas. This is possible because requests are processed locally without the need for the network, allowing the same database to be used across multiple servers and devices.

Furthermore, the introduction of features such as Periodic Sync, Read Your Own Writes, and Encryption at rest has led to Embedded Replicas reaching General Availability (GA) status, making them ready for production use.

We are still planning new features for Embedded Replicas in the future, like offline writes, and will keep improving the feature with your feedback.

Embedded Replicas can be seamlessly integrated with using libSQL SDKs for Node, Go, and Rust — learn more.

We can't wait to see what you build with it, and would love to hear from you on our Discord community!