apavlo

> couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries?

SQLite already compiles queries into opcodes and then uses its own VM to interpret them. You would have to reimplement the internal VM.

> I think if could say “this DB is posix only” I would try memory mapping for the next DB I build

Great! Please reach out to us after you learn (again) that this is a bad idea!

Please see the accompanying webpage with a 10min video:

https://db.cs.cmu.edu/mmap-cidr2022/

Yes, I need to fix the search. It's quite primitive right now.

Database of Databases - Embedded Systems

https://dbdb.io/browse?system-architecture=embedded

If you are a disillusioned PostgreSQL or MySQL DBA and are looking for a way out, then we have a job for you! OtterTune (https://ottertune.com) is looking for a plucky individual that wants to help us spread the message on how to use ML to automatically manage and configure databases.

* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...

This is a super important position to us, so you can email me directly if you want to discuss: pavlo@ottertune.com

Yes, of course it's me.

Apply anyway and let's chat.

If you are a disillusioned PostgreSQL or MySQL DBA and are looking for a way out, then we have a job for you! We are looking for a plucky individual that wants to help us spread the message on how to use ML to automatically manage and configure databases.

* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...

This is a super important position to us, so you can email me directly if you want to discuss: pavlo@ottertune.com

OtterTune | Full-time | Remote (US/Canada) | https://ottertune.com

OtterTune is a database optimization-as-a-service company. We use ML to automatically improve the performance of MySQL/PostgreSQL databases running on Amazon. We are a remote-first company. We are backed by Accel and the co-founders of Snowflake, DataBricks, SingleStore, CockroachDB, and Duolingo.

* Senior Front-End Engineer: https://jobs.lever.co/ottertune/ad9948ce-a542-4189-bd49-0bf3...

* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...

* Solutions Architect: https://jobs.lever.co/ottertune/0b14fbe7-d8b2-4d46-91fd-a6e7...

* UI/UX Designer: https://jobs.lever.co/ottertune/0b14fbe7-d8b2-4d46-91fd-a6e7...

* Director of Operations: https://jobs.lever.co/ottertune/2d077acf-7390-498c-9137-fa9e...

Legit compensation + equity. 401k w/ matching. PTO + sickdays + paid FMLA.

We are also hiring for many other roles: https://ottertune.com/careers/

Email us if you have questions: hiring@ottertune.com

If you are a disillusioned PostgreSQL or MySQL DBA and are looking for a way out, then we have a job for you! We are looking for a plucky individual that wants to help us spread the message on how to use ML to automatically manage and configure databases.

* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...

This is a super important position to us, so you can email me directly if you want to discuss: pavlo@ottertune.com

OtterTune | Full-Time Everything! | Remote (US/Canada) | https://ottertune.com

OtterTune is a database optimization-as-a-service company. We use ML to automatically improve the performance of MySQL/PostgreSQL databases running on Amazon. We are a remote-first company. We are backed by Accel and the co-founders of Snowflake, DataBricks, SingleStore, CockroachDB, and Duolingo.

* Senior Front-End Engineer: https://jobs.lever.co/ottertune/ad9948ce-a542-4189-bd49-0bf3...

* Developer Relations Engineer: https://jobs.lever.co/ottertune/486e1fdb-ceb6-44d4-872f-c66e...

* Solutions Architect: https://jobs.lever.co/ottertune/0b14fbe7-d8b2-4d46-91fd-a6e7...

* UI/UX Designer: https://jobs.lever.co/ottertune/0b14fbe7-d8b2-4d46-91fd-a6e7...

* Director of Operations: https://jobs.lever.co/ottertune/2d077acf-7390-498c-9137-fa9e...

Legit compensation + equity. 401k w/ matching. PTO + sickdays + paid FMLA.

We are also hiring for many other roles: https://jobs.lever.co/ottertune

Email us if you have questions: hiring@ottertune.com

I'm the author. Let's go through this.

> Like the article is titled "Ten Database Commandments", but the entire intro is all about the 25th anniversary of Biggie's sorrowful death.

I am huge fan of 1990s hip-hop. I try to incorporate elements of it (e.g., Biggie, Tupac, WuTang) in my academic courses on databases (https://www.youtube.com/c/CMUDatabaseGroup) and at the OtterTune company.

We even put out our own record label for database/otter-themed hip-hop music:

https://ottertune.bandcamp.com/

> The advice itself is really weak, like "never run your app on the same server as your DBMS", which is already common knowledge to database admins.

The commandments are targeting anybody deals with databases, not just DBAs.

Never get high on your own supply is obvious too but it's still one of Biggie's commandments.

> Is this article meant to be for Biggie fans?

Yes.

> Database admins?

Yes.

> Is it in memory of Biggie or making fun of him?

The former, not the latter.

> And what does The Notorious B.I.G. have to do with databases in the first place?

I'm not sure how one can listen to Biggie's lyrics and not think of databases.

What do you mean by "conflicted"?

This link should be to this page that includes more info and the accompanying video:

https://db.cs.cmu.edu/mmap-cidr2022/

Be sure to also check out OtterTune Records. It is the premier record label for otter and database related street music: https://ottertune.bandcamp.com

OtterTune | Junior/Senior Frontend/FullStack | Remote | https://ottertune.com

OtterTune is a database optimization-as-a-service company. We use ML to automatically improve the performance of MySQL/PostgreSQL databases running on Amazon. We are a remote-first company. We are backed by Accel and the co-founders of Snowflake, DataBricks, SingleStore, CockroachDB, and Duolingo.

* Senior Front-End Engineer: https://jobs.lever.co/ottertune/ad9948ce-a542-4189-bd49-0bf3...

* Senior Full-Stack Engineer: https://jobs.lever.co/ottertune/762d0365-f00b-43de-a3a1-37f7...

* Product Manager: https://jobs.lever.co/ottertune/a7fcb8f8-4bd1-45a4-a29b-0723...

We are also hiring for other roles: https://jobs.lever.co/ottertune

Email me if you have questions: pavlo@ottertune.com

> Databases in 2030: SQL DB finally succumbs to Graph DB as #1

Graph databases will not overtake relational databases in 2030 by marketshare.

Bookmark this comment. Reach out to me in 2030. If I'm wrong, I will replace my official CMU photo with one of me wearing a shirt that says "Graph Databases Are #1". I will use that photo until I retire, get fired, or a former student stabs me.

If you want to be even more overwhelmed, see my encyclopedia of database systems:

https://dbdb.io/

I was not being sarcastic. Larry is a good man.

We are very careful to make sure that we don't allow the tuning algorithms to make changes that could be detrimental to the correctness or availability of the database. This blog article describes some of the safeguards that we employ:

https://ottertune.com/blog/prevent-machine-learning-from-wre...

We also advise our customers to not point OtterTune at a production database right away.

> I think DB tuning seems like a perfect business opportunity

I got you fam: https://ottertune.com/

SMHasher benchmark numbers are here (including Meow Hash):

https://github.com/rurban/smhasher#readme

MSSQL is the #1 requested DBMS for us after Postgres and MySQL (RDS and Aurora). Reach out to us about what you need and we can let you know if this is something we could add soon: https://ottertune.com/contact

Correct. We could add support but most of our requests have been for MySQL and Postgres. Hit us up if you really want MariaDB: https://ottertune.com/contact

Right now it automatically applies them. Reach out to us to tell us how you want the product to work with your setup: https://ottertune.com/contact

> If I may, can you please shed light on why Peloton had to be archived and in essence re-done with OtterTune. Interested in your team's learnings from it from a software engineering point of view.

Peloton and OtterTune are completely different projects. Peloton was abandoned and rewritten as NoisePage (https://noise.page). OtterTune has always been OtterTune.

See this recent interview where I discuss why we gave up on Peloton:

https://www.ibm.com/cloud/blog/database-deep-dives-with-andy...

> - How did the team ensure this project doesn't suffer from the same disadvantages as its predecessor?

Again, different projects. OtterTune is all about not having to modify the internals of Postgres, MySQL, and any other DBMS. This is why we were able to support Oracle in the academic version in a short amount of time:

https://ottertune.com/blog/vldb-autonomous-database-tuning-i...

> - What would you advise other teams undertaking a rewrite to pay off their tech debts?

It is hard for to provide general advice for this question because every situation is different.

> How does this project compare to / contrast with Google's and SingleStore's efforts in this space?

I am not familiar with Google or SingleStore using ML in the manner that we are with OtterTune to tune configuration knobs. Or at least I have not seen anything public about it.

These days Oracle is the most aggressive with pushing automated tuning capabilities (Oracle's autonomous DBaaS, AutoPilot for MySQL Heatwave). The difference with these approaches and OtterTune is that right now we are focused on configuration tuning (to avoid data privacy issues) and our core approach is platform/DBMS agnostic.

> Any chance we see you do a Peter Bailis and Sisu Data this? (:

I don't know what you mean by this? Peter Bailis is the Ryan Gosling of databases.

We overlooked this. You are right about the number of users being artificially low for our standard plan and we will adjust. More databases is the more expensive part on our side. Thanks for feedback.

We are still measuring how much we are able to optimize Aurora with customers in private beta deployments. Aurora is trickier than RDS because Amazon removed a bunch of config knobs when they rewrote the storage layer. So reducing Aurora costs requires more aggressive tuning strategies (e.g., autovacuum) than RDS, which is why we don't want to just let anybody use it right now. It requires more time on our part to make sure that things go smoothly.

Optimizing MySQL/Postgres RDS in the free version is low risk.

Thanks! Word is bond.