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 watching the show can still learn some valuable lessons about dealing with databases from the show if they’re willing to apply a bit of creative interpretation. So, without further ado, here are seven 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, 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! But it will frustrate your users, which could produce the same end result in the long run. 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, and particularly distributed 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 313 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, and 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-cloud and/hybrid cloud solutions. No matter what kind of system you set up, you’ll have node outages. AZ outages. On a long enough timeline, you’ll probably have region outages and 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) multi-cloud deployments to survive even the worse outages. (Did we mention CockroachDB supports multi-cloud?)
“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 serverless computing options is making it cheaper and easier than ever to build potentially world-scale applications. Developers want to spend their time and energy building amazing things, not trying to figure out how to shard their database or deal with consistency problems.
We built CockroachDB Serverless, a free serverless distributed SQL database, to enable developers to spend more time building what they dream, and less time worrying about the database. And we strongly suggest you give it a try!
But even if you don’t, 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 developers 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 all about Kubernetes using the movie Titanic!
