Star Trek: The Next Generation may have stopped airing in 1994, but it’s a series that’s always rewarding to return to. Arguably the most cerebral of the various Star Trek film and television series, the best episodes of TNG are just as thought-provoking today as they were when they were first televised.
Admittedly, TNG was not a series about databases. But modern developers and architects watching the show can still learn some valuable lessons about dealing with databases, as long as they’re willing to apply a bit of creative interpretation.
So, without further ado, here are eight valuable lessons about the database, as understood via quotations from TNG:
“Mr. La Forge, time is one thing we do not have in abundance.”
– Jean-Luc Picard in “Contagion”
This episode revolves around the crew of the Enterprise struggling to deal with a virus that has infected the ship’s computer after they brought over data logs from another Federation ship in an attempt to understand how it was destroyed. In and of itself, that’s a valuable database lesson – it’s important to implement security measures and strict schema to prevent “dirty” or malicious data from getting into your database.
But Picard’s exhortation that time is limited brings to mind an even more fundamental database lesson for the modern era: speed matters. Users increasingly demand incredibly low latency from all of their apps, and the database can easily become a speed-killing bottleneck, particularly if it’s not distributed and scalable. If a transaction has to travel halfway across the world and then get in line behind thousands of others before it can be committed to a single-instance database or a distributed database that can only support writes on a single node, the end user experience is going to suffer.
Admittedly, even in that scenario, we’re better off than the Enterprise was – having a slow database will not make your application explode, at least in the literal sense. But it can harm performance and, under heavy enough traffic, take your application offline. To avoid having our applications go the way of the Yamato, we need our database to be fast.
In the modern era, this means it needs to be able to scale – vertically, horizontally, and geographically.
“When the Borg destroyed my world, my people were scattered throughout the Universe. We survived. As will humanity survive. As long as there’s a handful of you to keep the spirit alive, you will prevail.”
– Guinan in “The Best of Both Worlds Part 1”
Speaking of distributed systems, in this classic episode Guinan makes what can certainly be read as a strong argument for a distributed database: distributing things makes them more difficult to kill.
Thankfully, there’s no Borg-like threat out there hell-bent on assimilating our databases. But even the most advanced software is still reliant on hardware, and hardware is susceptible to the violent entropy of the physical world. If your database isn’t distributed, it’s only going to be a matter of time before a power failure or a flood or any of a thousand other potential hazards knocks it offline, taking your entire application with it.
But, much like Guinan’s people (the El-Aurians) survived by scattering throughout the universe, our databases can stay online if we “scatter” and replicate our data across multiple nodes, availability zones, and regions. In fact, this ability of the distributed database to survive is where CockroachDB gets its name – like cockroaches, it is very difficult to eliminate!
“Captain, we’re receiving two-hundred and eighty-five thousand hails.”
– Wesley Crusher in “Parallels”
In this episode, Worf passes through a space-time fissure on the way home from a bat’leth tournament and accidentally wreaks havoc on the space-time continuum. At one point, thousands of separate, parallel universes are merged, and the Enterprise receives 285,000 hails from parallel versions of itself, with additional parallel Enterprises appearing at an exponential rate.
Obviously, most of us don’t have to deal with parallel universe databases, or worry about fissures in the fabric of space-time. But the fleet of parallel ships does remind me of a problem that databases sometimes have to deal with: multiple concurrent transactions trying to act on the same row. Just as it becomes difficult to know which Enterprises belong where, it can become difficult to parse how transactions should be ordered when they’re being processed concurrently across multiple nodes in a distributed system.
The solution to this problem is ACID transactional guarantees, and more specifically, serializable isolation, the strongest level of transactional isolation. You can read more about isolation levels here, but long story short: choosing a database that has ACID transactional guarantees and serializable isolation (such as CockroachDB) ensures that your database can handle concurrent transactions correctly.
“Listen, my advice is: ask somebody else for advice. At least someone who’s got more experience at… giving advice.”
– Geordi La Forge in “In Theory”
In his quest to understand human love, the android Data goes to Enterprise chief engineer Geordi La Forge for advice, and doesn’t get much help. La Forge, who despite his best efforts never has much romantic success, at least has the self-awareness to know that he’s probably not the best person to guide Data through a budding relationship.
Unfortunately, people on the internet aren’t always so self-aware when it comes to handing out advice to others. The database lesson here – and this is really a lesson that relates to learning anything – is that we should be careful who we get our advice from. StackOverflow and Google are very valuable tools, but who’s writing the answers you’re reading?
Thankfully, in the context of databases, there tend to be very reputable sources we can go to when we need help. The documentation is always a great place to start, but if that doesn’t help you, most modern database vendors offer a variety of other ways to get help. Here at Cockroach Labs, in addition to our excellent documentation, we’ve got a blog, webinars, online courses, sample apps, guides, a community Slack, a support portal and more!
In other words: don’t go to Geordi La Forge for romantic advice! When you’re learning and configuring your database, be sure you’re getting your information somewhere reputable so that you can be confident it’s accurate and up-to-date.
(Geordi La Forge would probably be a great person to ask for database advice, but he’s fictional and won’t be born for another 311 years anyway, so I recommend you start with the docs).
“There. Are. Four. Lights.”
– Jean-Luc Picard in “Chain of Command”
It’s one of the most memorable moments of the series: Captain Picard is being held and tortured by the Cardassian Gul Madred. At first, Madred appears interested in collecting military intelligence, but Picard refuses to comply. Madred’s focus shifts towards trying to break Picard psychologically by showing him four lights, insisting that there are actually five, and torturing Picard each time he defiantly repeats the truth.
Picard’s insistence on sticking to the truth – to maintaining correctness even under extreme duress – is a virtue for databases, too. There are very few scenarios in which it would be considered acceptable for a database to contain incorrect information, but the threat of that is very real.
Consider a simple example of concurrent transactions acting on the same row in the following sequence:
Tx 1 begins, bank deposit: update account balance to 100
Tx 2 begins, bank deposit: update account balance to 150
Tx 2 finishes processing and commits. Account balance is set to 150.
Tx 1 finishes processing and commits. Account balance is set to 100.
In this scenario, the final bank balance should be 150, but it’s set to 100 because the second transaction completes and is committed first. And while this is a very straightforward and simple example, remember that a production database at scale may need to handle thousands of transactions or even more per second.
So how many lights does your database see? If you value correctness the way Captain Picard does, you’ll want a database that can enforce ACID guarantees (ideally with serializable isolation) to ensure that no matter what it’s up against, it’s always going to see four lights when there are four lights there.
“It is possible to commit no mistakes and still lose. That is not a weakness; that is life.”
– Jean-Luc Picard in “Peak Performance”
This is one of Captain Picard’s most universally applicable life lessons. In the episode, he is counseling Data, who has become convinced he’s malfunctioning after losing a game of Stratagema. But it’s a good thing for developers to keep in mind, too.
It doesn’t matter how well you set up your database, what machines you provision, etc. At some point, something is going to go wrong. It may be your mistake, it may be someone else’s, or it may be nobody’s mistake at all. Sooner or later, bad luck comes for us all.
This is why it’s good to have the protection that comes from a distributed database, and for mission-critical workloads, to consider multi-region, hybrid, or multi-cloud deployments. No matter what kind of system you set up, you’ll have node outages. You’ll have AZ outages. On a long enough timeline, you’ll probably have region outages and potentially even cloud provider outages.
But none of those things have to mean database outages or outages for your application if you’ve prepared in advance and chosen a distributed database that can support (for example) a broad variety of deployments to survive even the worst outages. (Did we mention CockroachDB supports all three major cloud providers, on-prem deployments, multi-region deployments, and multi-cloud deployments?)
“It’s easy. Just change the gravitational constant of the universe.”
– Q in Déjà Q
When Q, a being of extraordinary power, is temporarily turned into a human as punishment, he has a little bit of difficulty seeing things from a human perspective. Asked to aid the crew of the Enterprise in moving a moon that is falling out of orbit, Q makes suggests the ship’s engineers simply change the way gravity works in the universe, which is far beyond the abilities of even the 24th-century humans depicted in the show.
People sometimes talk about database operations in a similar way. ‘Oh, you’re not satisfied with your current database? Just migrate!’
Needless to say, it’s never quite that simple. What seems “easy” at a distance, as Q learns, is rarely quite so easy in practice.
Next-gen database features such as CockroachDB’s migration tooling, support for schema changes without downtime, simple geo-partitioning, and more can definitely make things easier. But for mission-critical workloads at scale, it’s almost never going to be totally easy, so it’s important to (1) choose a database management system you can trust to do some of the hard stuff for you and (2) choose a database company that you can trust to partner with you to help you figure out the hard stuff. (Or just choose one of our managed DBaaS options and let us worry about the hard stuff.)
“The time for glory is here! It is not a time to worry about stabilizers!”
– Kern in “Redemption Part 2”
Everyone knows that Klingons love a good battle. So when Worf fails to embrace the excitement of the moment because he’s worried about the stabilizers on their ship, his brother Kern chastises him. Huge, important things are happening, and he wants Worf to embrace and enjoy it rather than worrying about technical minutiae.
Shouldn’t developers do the same? We are living in an exciting era, when the explosion of cloud computing options is making it cheaper and easier than ever to build potentially world-scale applications. Your dev and ops teams want to spend their time and energy building and scaling amazing things, not wasting their time with manual database management and ops work or time-consuming projects like manual sharding.
We built CockroachDB to enable you to scale where others fail, enabling mission-critical workloads at global scale while reducing the ops and management burden normally associated with SQL databases at that scale. But you don’t have to take our word for it – read some case studies and see how we’ve helped our customers achieve high availability and elastic scalability.
Even if you don’t read a case study, I hope you’ll take Kern’s words to heart. Now is the time to build cool things. It’s the time for glory. So whether it’s CockroachDB or something else, find a way to free yourself from the burden of worrying about stabilizers your database so you can focus on what really matters.
Your future customers will thank you.
Is Star Trek: The Next Generation a good way for people to learn about databases? Probably not. I’ll admit that turning Star Trek quotes into meaningful database lessons requires some creative interpretation. But it can still be a helpful way to reinforce some of these ideas.
Want to keep the learning train rolling? Learn how the Raft consensus algorithm works via the movie Mean Girls!
