Microservices: The Data Ownership Trap
Microservices promise agility and scalability, but there's a hidden pitfall that can derail your chosen architecture: shared data.
Microservices promise agility and scalability, but there's a hidden pitfall that can derail your chosen architecture: shared data.
Most engineers think they understand transactions until they deal with distributed systems, different storage engines, or frameworks that abstract too much.
The strongest junior DBAs for operational systems come from software development backgrounds with a genuine passion for data.
They’ve built apps, optimized queries, and experienced firsthand the pain of poor database decisions before transitioning into a DBA role.
I learned something new today about Postgres!
Laurenz Albe’s blog post on how you can break foreign keys in Postgres includes the tidbit that BEFORE triggers that return NULL can stop enforcement of foreign keys.
While I knew system triggers enforced referential integrity in Postgres, I had not considered the consequences of BEFORE triggers with that feature.
Learn more from Laurenz Albe here:
One valid use case for stored procedures in operational systems can be to reduce round trips to the database for some transactions. In (some) databases, it can also mean running compiled code close to the database.
Both are more efficient in some cases, but it can also be more difficult to debug stored procedures than normal code.
Quoted database object names are like getting dysentery on the Oregon Trail
... It’s not gonna end well.
Adrien Nayrat has an excellent article that delves into what many have forgotten about the DBA (Database Administrator) role.
A common question from people moving from other databases to Postgres is how can I learn more?
One of the great things about the Postgres community is the excellent documentation!
While I don’t have any affiliation, Postgres Weekly is a great way to learn something new and keep tabs on Postgres news.
"If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime." ~ Anonymous
While database engineers (and administrators) want to be helpful and answer questions, you should not expect your database engineer to:
Security access controls extend into your databases. The principle of least privilege needs to be enforced not only for who can connect but also for what they can do within your databases.
For example, until PostgreSQL version 15, PUBLIC (which all users are a member of) could create tables within the public schema unless REVOKE’d. This is just one example.
It’s important to review what the security defaults are for your database product to ensure you are enforcing the least privilege access model where you explicitly grant access to resources.