DBMS or Database?
As front-end developers increasingly own the data layer, the terms we throw around casually deserve some precision. Strictly speaking, the software we call a “database” is a Database Management System (DBMS) — the piece of software that makes it ergonomic to write, read, delete, or update information in a dataset. Relational and non-relational DBMSs dominate web development, even though many other types exist, categorized by their data structures.
Both relational (R) and non-relational (NR) systems share conceptual building blocks, though they use different names. Developers routinely say “table” when referring to a non-relational “document,” which is understandable — the definitions overlap enough that the confusion fades quickly with use. In practice, the differences matter more than the similarities, but for now the parallels help us build a common vocabulary:
- Schema: A blueprint describing the structure of the database in a supported language. Relational databases require it; non-relational systems don’t, although many interfaces allow you to define one.
- Tables (R/NR), Collections (NR): The unsorted logical data structure. Think of a spreadsheet table or a group of JSON objects.
- Databases (R/NR): A logical grouping of data — tables in relational systems, documents grouped by intended query pattern (often called “indexes”) in non-relational systems.
Keys, Columns, and Relations
Consider a typical JSON record:
{
"name": "Atila"
"role": "DX Engineer at Xata"
}
Each key-value pair corresponds to a column: the column name holds the value “Atila,” and the key works exactly as defined in the JSON spec. A table has columns, and each column’s name determines the key you use to access a value in a record.
Some keys are special because they define the shape of your schema and how you interact with your data. These deserve careful design — a minimal change to them can count as a breaking change to the data layer.
- Unique Keys (UK): Unique across records in a table. They may accept
null. - Primary Keys (PK): A special unique key. Each table has exactly one, it can never be
null, and it is indexed by default to speed up query filtering. - Foreign Keys (FK): Represent relationships between tables. The key appears at the referencing (extraneous) table.
If each author in an authors table has posts in a separate posts table, then a field like post.title is a foreign key on the author record. The junction between the two tables is a relation:
From Data Layer to Application Layer
Once you pick a DBMS based on its data structure, you still face the task of wiring it into your application. Object Relational Mapping (ORM) and Object Document Mapping (ODM) tools exist to ease that translation between database structures and application objects. Prisma is currently the most widely used ORM; Mongoose leads among ODMs.
These libraries are not strictly required to connect to a database. Used with care — particularly by watching how they construct queries, since some abstractions introduce performance overhead — they tend to make fetching and writing data much more ergonomic. However, with serverless databases the calculus shifts. Many of them ship official Software Development Kits (SDKs), which often overlap heavily with ORM/ODM features, especially when the database keeps the data layer behind an API (Xata is one example). In such cases, you can skip the query translation entirely and still expect the same ergonomics you’d get from an ORM.
Distributed Data, Three Tradeoffs
The following concepts apply to every data layer — spreadsheets, self-hosted databases, and serverless options alike. The difference is in how each solution balances the variables involved:
Three concepts stand out as the starting point: Consistency, Availability, and Partition Tolerance. They are best understood together because their balance determines how predictable your data will be across contexts.
The CAP Theorem
The CAP Theorem describes the relationship between these three components in a distributed system. The conclusion is deceptively simple: any system can fully deliver only two of them at a time.
- Consistency (C): Different clients making the same request get the same response. A confirmed write is visible to all users at the same time.
- Availability (A): Every request receives a response with data — no errors — but with no promise the data is current.
- Partition Tolerance (P): A “partition” is a broken connection between two nodes. The theorem concerns how a system behaves under that condition: it can enforce availability (an AP system) or consistency (a CP system). Since partitions are always possible — no matter how small the system — a CA system is effectively impossible
Graphically, you can think of the tradeoff in common implementations:
- AP System: Another node holds a data copy, so requests get answers — but not necessarily 100% up-to-date ones. Typical choices: DynamoDB, Cassandra.
- CP System: Return an error rather than accept a transaction that can’t be confirmed. Typical choices: traditional sharded databases like Citus.
Popular as it is, CAP is incomplete. It only reasons about network partitions, ignoring latency and subtle consistency aspects like linearizability and serializability — significant blind spots in today’s world of CDNs and always-on connectivity.
Consistency, Refined
“Consistency” shifts meaning depending on context. In CAP, it means your data is reliably the same across partitions. Step back from a single request, and a second interpretation emerges in the context of your own system: how consistently you handle concurrent operations. A third definition waits in another acronym entirely, ACID. Alex DeBrie’s Inconsistent Thoughts on Database Consistency untangles these layers well for anyone seeking clarity.
The PACELC Theorem
PACELC extends CAP’s scope. The first three letters are CAP reordered, but the consistency definition deepens: it follows the Consistency Model, the contract between the data store and your system.
PACELC considers not just partition strategy but also what happens on a healthy network — ELC: Else, Latency or Consistency?
- Latency: Can you accept an occasional stale response for performance?
- Consistency:
- Linearizability: Will you tolerate higher latency to sync every node before acknowledging a transaction?
- Serializability: When transactions hit the same data concurrently, will you handle them in parallel or queue them?
That spectrum is precisely why PACELC feels like the better mental model for the serverless era. It does not reduce you to one of two labels — AP or CP. On a healthy network, latency ranges and consistency levels vary, so the design space is far richer than CAP alone suggests.
As we get closer to comparing database types and their data structures — and their guarantees — system architecture starts to matter. Careful architecture can mitigate tradeoffs, so that even while enforcing consistency, you can still keep latency low.
The groundwork is set: what distinguishes database types easily, what to expect from each, and how those expectations shape the data layer. The next step is tackling relational and non-relational systems head-on: the guarantees each makes, what those mean for your data, and how different structures affect your development workflow.
