We've consistently heard teams describe challenges with the way manual data updates are handled. Seemingly every engineer we spoke with had examples of errant queries that ended up causing significant harm in production environments (data loss/service interruptions).
We’ve seen a few different approaches to how changes to production databases occur today:
Option 1: all engineers have production write access (highest speed, highest risk)
Option 2: one or a few engineers have write access (medium speed, high risk)
Option 3: engineers request temporary access to make changes (low speed, medium risk)
Option 4: all updates are checked into version control and run manually or through CI/CD (low speed, low risk)
Option 5: no manual updates are made - all changes must go through an internal endpoint (lowest speed, lowest risk)
Our goal is to enable high speed changes with the lowest risk possible. We’re planning to do this by providing an open-source toolkit for safeguarding databases, including the following features:
- Alerts (available now): Receive notifications any time a manual change occurs
- Audit History (beta): View all historical manual changes with context
- Query Preview (coming soon): Preview affected rows and query plan prior to running changes
- Approval Flow (coming soon): Require query review before a change can be run
We’re starting with alerts. Teams can receive Slack notifications anytime an INSERT, UPDATE, or DELETE is executed from a non-application database user. While this doesn’t prevent issues from occurring, it does enable an initial level of traceability and understanding who made an update, what data was changed, and when it occurred.
We’d love to hear feedback from the HN community on how you’ve seen database changes handled, pain points you’ve experienced with data change processes, or generally any feedback on our thinking and approach.
