Watch the webinar
Once you live in a distributed world, it becomes apparent that the database itself could actually take care of domiciling data. With participants located in various regions or data centers, it becomes possible to understand the location of each and then tie the data that it stores to a location. Some application architects have implemented this as part of an application but this approach is error-prone and brittle. Using the database to geo-partition data based on some field in a table is a new requirement for Distributed SQL. This allows you to use the database to address data sovereignty concerns. It can also be used to have data follow a user so you can ensure low latency access to their information or to tie data to an explicit cloud so you can minimize egress charges.
A distributed SQL database must deliver a high level of isolation in a distributed environment. In a cloud-based world with distributed systems and microservices are the default architectures, transactional consistency becomes difficult as multiple operators may be trying to work on the same data. The database should mediate contention and deliver the same level of isolation of transactions as we expect in a single instance database.Other important concepts that are unique to distributed SQL and should be kept in mind during an evaluation of any distributed database are Latency, Resilience, and Compliance. Make sure that the latency goal is to achieve the speed of light, because, well, that’s as good as it gets. Confirm that the database will not experience any downtime when, inevitably, a node fails. And make sure that the data locality that is being discussed will help you achieve compliance with the suddenly proliferant data storage regulation laws around the world.For a more detailed analysis of Distributed SQL architecture please watch this webinar.After you’ve watched the webinar please join our CockroachDB Community Slack channel to chat with CockroachDB users and engineers.