What is StatelyDB?

StatelyDB is a serverless document database that solves the schema evolution problem. Unlike traditional NoSQL databases where schema changes require careful coordination and manual data migration, StatelyDB automatically handles schema evolution while maintaining backwards compatibility with all existing applications.

StatelyDB currently uses DynamoDB as its storage engine, giving you all the scalability and reliability benefits of AWS’s managed database service, but with a dramatically improved developer experience through our Elastic Schema system.

We were inspired by DynamoDB when we decided to build StatelyDB, but we wanted to push far further into the vision of what you could do with an abstraction layer over a NoSQL datastore, especially once you have a schema that describes how the database should handle your data.

StatelyDB’s signature feature is Elastic Schema, which lets you describe your data model, generate code to work with those types, and then enables you to change your data model at any time. The database automatically migrates data where necessary, while maintaining backwards compatibility with all previous versions of schema. This eliminates the need to coordinate deployments or carefully consider the impact of data model changes on existing clients.

At its core, StatelyDB:

• Is a partitioned document database that prioritizes scalability and low operational overhead.
• Provides a developer-friendly API that you interact with via generated code that reflects your own data types.
• Uses Elastic Schema to describe your data model, generate type-safe code, and provide automatic backwards compatibility as you change your data model. Elastic Schema makes change safe, easy and predictable.
• Makes it easy to build single-table data models that optimize for efficiently getting all the data for a use case in a single request.

How StatelyDB Works

StatelyDB sits between your application and DynamoDB, providing:

1. Schema Management: Define your data model once, generate type-safe code for multiple languages
2. Automatic Migrations: When you change your schema, StatelyDB handles data transformation automatically
3. Backwards Compatibility: Old applications continue working even after schema changes
4. Optimized APIs: Higher-level operations than raw DynamoDB, with better performance

Frequently Asked Questions

What does StatelyDB have to do with DynamoDB?

StatelyDB uses DynamoDB as a simple storage engine to persist and retrieve data. DynamoDB is a managed database service from AWS that’s built to scale forever with low operational overhead. We chose it as our first storage engine because we were inspired by its design, and we have experience operating it at scale. We also wanted to be able to offer world-class guarantees for scalability, availability and durability from day one. See StatelyDB vs. DynamoDB for more details. Eventually we will add more storage engines to provide cross-cloud capabilities or offer different price/performance tradeoffs.

So is StatelyDB just a wrapper around DynamoDB?

StatelyDB is a new database with its own API and a growing set of advanced capabilities. We just use DynamoDB for basic storage operations. On top of that, StatelyDB layers on a rich Elastic Schema system, powerful SDKs, and highly optimized APIs. See StatelyDB vs. DynamoDB for more details.

Is StatelyDB just an ODM (Object Document Mapper) or ORM for DynamoDB?

It could be tempting to think of what Elastic Schema does like an Object Document Mapper. ODMs are usually client libraries or code generators that help map your in-memory models to a document database’s APIs (for relational databases this is called an Object Relational Mapper or ORM). An ODM is effectively an application layer solution—it is used in your code to make it easier to work with a database. In contrast, in StatelyDB the database itself knows about your schema and can take actions and make decisions based on it, including validating your data, transforming it between versions, and providing backwards compatibility with older versions. Regardless of how many applications talk to the database, all of them gain these benefits because in StatelyDB, the schema is a data layer concern, not an application layer concern.

Does it use the same API as DynamoDB?

StatelyDB has its own API that’s both easier to use and more powerful than DynamoDB’s. Importantly, StatelyDB’s APIs speak in terms of your own data model as expressed through schema. This means you save a User object or an Order object, instead of saving a JSON document or a map of key/value pairs.

Can I use StatelyDB with an existing DynamoDB table?

Because DynamoDB is an implementation detail of StatelyDB’s storage engine, we have specific ways we store data in and interact with DynamoDB that wouldn’t work with an existing table. And, if you had applications that talked directly to the DynamoDB table and through the StatelyDB API, we could not guarantee correctness like we normally would.

However, we do have an idea for how to “adopt” existing DynamoDB tables into StatelyDB and provide a gradual migration path. If this is interesting to you, please reach out! We’d love to partner with you as a reference customer for this feature.

How does this compare to other NoSQL databases like MongoDB?

StatelyDB is similar to other NoSQL document databases like MongoDB, especially their hosted offering. MongoDB currently has some features that StatelyDB does not, but it crucially lacks schema tools. You can either use a third-party ODM, or leverage some built-in JSON schema for validation, but there are no provided tools for migrating data or managing backwards compatibility.

How does this compare to relational/SQL databases like Postgres?

Partitioned document databases like StatelyDB are very different from SQL databases like Postgres. While relational databases focus on flexible and powerful query capabilities, they fall down in scalability and consistent performance. As your stored data grows and your access patterns get more complicated, performance and operational problems crop up and you end up in a lot of trouble trying to scale out your data layer. In contrast, partitioned document databases like StatelyDB don’t offer complex query languages and instead encourage you to write data in a structure that is most efficient for it to be read, ensuring consistent performance no matter how much traffic you get and how much data you’ve stored. Lots of folks are working on ways to make SQL databases scale, and we wish them luck, but that’s not the approach we’ve taken when building huge applications at Snapchat and Amazon.

What do you mean DynamoDB is StatelyDB’s first storage engine?

It means that in time, we’ll have other storage engines that offer different properties—lower costs, higher performance, or availability outside AWS are all considerations. Since our data layer is abstracted from the schema and API layers, we can swap DynamoDB out for other options as necessary. If you have a different backend you’d like, please reach out! We’d love to partner with you as a reference customer for this feature.

Is StatelyDB only available as a hosted API?

While our hosted service is an easy way to get started and can scale up to huge workloads, we anticipate that most users will want to user our BYOC (Bring Your Own Cloud) deployment model that keeps your data and AWS resources in your own AWS account. You can try either mode for free today!

How much does StatelyDB cost?

StatelyDB is free to try in both our hosted and BYOC models. Once you’ve had a chance to try it out, contact us for pricing and support in adopting StatelyDB.

What programming languages are supported?

We currently support Go, Python, JavaScript/TypeScript, and Ruby. If you would like to use a different language, let us know as we can quickly spin up new SDKs.