2 Billion MySQL Records

Yesterday Gary Gray, a friend of mine sent me the following screenshot. He's got a database table with 2 billion records he intends to use Magic on, and he wanted to show it to me, thinking I'd probably be like, "That's cool." Gary works for Dialtone in South Africa, and is used to handling a "monster amount of data". For the record, neither Gary nor I would want to encourage anyone to handle 2 billion records in MySQL, but as you can obviously, see it is possible.

This of course is a legacy system. If it was started today, Gary would obviously use ScyllaDB, Cassandra, or something similar. Simply counting the records in the table above requires 5 minutes of execution in MySQL workbench. Obviously, such sizes are not for those faint at heart. Such a database also implies a lot of inserts.  This makes it impossible to add indexes, resulting in every select query you do towards it having some sort of where clause in it that implies a full table scan. However, it is possible.

The First Stages of Feature Flag Adoption

For quite a while now, developers have used snippets of code to turn features on and off during runtime. These code snippets, more commonly known as feature flags, allow you to change features (or sub-sections) of your application without re-deploying. They help developers release code faster, with less risk. 

Feature flags are more prevalent than you might believe. At most companies, though, adoption begins at the grassroots level. Developers—usually within a single team, and often just a few individuals—implement a handful of feature flags in an ad hoc way. In these early stages, feature flags aren’t usually being considered at a systemic level. They’re meant to solve specific pain points at specific points in time. There is no formal program in place, and there are no plans to manage flags across teams.