MariaDB 10.5 起支援以 S3 作為儲存載體，以及 InnoDB 引擎與 MySQL 的差異越來越大，也開始逐步停用當年為了保持相容性的 mysql 命令。
MariaDB 正逐漸走出自己的路，過往 MariaDB 與 MySQL 都有十分良好的相容性，一直以來甲骨文都無心刻意維持和 MariaDB 的相容性，但自 MariaDB 10.5 起它們之間的差異會越來越大，比較矚目的是支援 S3 做為儲存載體，但目前僅能把整份 table 用 ALTER 命令移到 S3 上，在 S3 上的 table 只能讀（查詢），不能增刪改紀錄，詳細的說明可以參考 MariaDB S3 Engine: Implementation and Benchmarking 一文。
Oracle 推出 MySQL 的代管服務，最大的優勢很明顯，就是第一方代管，而且宣稱價錢比 Amazon 的 RDS for MySQL 便宜，但遺憾的是可能還是無法受到太多的青睞，在雲端領域落後的甲骨文因為固有的形象與種種其它因素，在沒有大刀闊斧轉變前看起來都很難往前超越對手，在台灣市場，雲端領域前段班的 Amazon 和 Google、微軟都有在地的深耕經營，而排名後面的甲骨文反而幾乎沒有投注資源，幾乎是佛系打法，這麼有距離感的經營方式，怎麼看都不像能超車的感覺。
Barebackups 是個資料庫的備份服務，運作的機制相當簡單，它透過 SSH 進入我們的資料庫主機，把資料庫 dump 成 .sql 檔案，再把檔案複製到 Barebackups 的空間存放，或者也可以放到我們自己的 S3 空間。
儘管這是個頗為單純的服務，或者也可以說很陽春，但確實有解決資料庫要異地備份的問題，從創業的角度來看，也是個很好的 MVP 案例，許多的創業團隊都把事情想的太複雜，或者說在腦力激盪的過程中發現太多的窒礙，如果又遇到是工程師出身的團隊，那往往就走進規格越開越複雜，上線也越來越遠的死胡同，面對非 MVP 但又預期會遇到的問題，正確的作法應該是了解並擱置，先追求把 MVP 推向市場，獲取用戶的認同，再逐步改善，在上市前的預想的 P0 級問題很有可能在上市後根本不復存在，因為產品根本沒人用，或者用戶反饋之後產品路線做了大幅修正，讓上市前的大問題變得微不足道。
對 Barebackups 開發歷程有興趣的讀者，可以拜訪 Barebackups 在 Indie Hackers 的頁面。
MySQL 核心的儲存引擎，在 5.5 版以前是 MyISM，之後改用 InnoDB，但用戶仍可以自行配置為 MyISM 引擎。InnoDB 相較於 MyISM，多了一些特性：事務處理、外鍵、行級鎖等。
RethinkDB 是 NoSQL 系的資料庫系統，主要特色是支援對查詢結果的即時串流。
RethinkDB 和 MongoDB 同樣是 NoSQL 的資料庫系統，但在架構和特色上，除了支援查詢結果的即時串流外，RethinkDB 的查詢語言 ReQL 也頗為獨到，RethinkDB 有開發各種語言的套件，主要有 JavaScript、Python、Ruby 和 Java，而 ReQL 並非像 SQL 那樣有自己的語法，而是都和程式語言緊密結合，只要在程式專案內引入 RethinkDB 的套件，就可以利用套件內提供的函式發出查詢，不用再學習另外一種語言，另外 RehinkDB 也支援 JOIN 的查詢，這和 MongoDB 或其他 NoSQL DB 也相當不同。
在 RethinkDB 的 FAQ 文件內有更多 RethinkDB 的特性介紹，可以一讀。
TiDB 執行長兼產品經理分享 TiDB 發展的歷程，原文頗長，下面摘錄幾個觀點：
人類對於未知的東西很難做一個精確的推導，這時信念就變得非常重要了
這點和賈伯斯頗類似，初創產品一定要有核心精神，市調或 MVP 只是用於佐證你的核心精神是否被普遍認同，而拿市調當作產品的初心，那只會讓團隊迷失方向。
永遠站在離用戶更近的地方去考慮問題
離用戶近表示更短的 time to market、更快的 MVP、更快的收到用戶反饋。
Makr it work, make it right, make it fast
可以直觀的理解成先求有再求好，效能問題只要不是瓶頸都可以先略過，Facebook、Twitter 也都經歷過架構重構，因為他們當時並不知道自己會長那麼大，企圖在前期追求架構的絕對正確性是不現實的，架構沒有停止調整的一天， 因此也不存在絕對正確的形式。
Timescale 是個以 PostgreSQL 為基礎的資料庫系統，加上為時間序列資料優化的儲存結構與查詢語法，傳統的資料庫的效能會受到索引的影響，表格越長，索引也越大，當索引大到記憶體吃不下的時候效能就會開始下降，而 Timescale 的時間序列儲存結構會自動把很長的表格依照時間切成小塊（chunk），每次只會載入需要的小塊做操作，因此不管表格多長，操作的效能都能維持在同樣的水平，並且這樣的儲存機制對 DBA 人員來說是透明的，Timescale 底層的儲存機制會自動管理。
Timescale 除了儲存結構對時間序列資料做優化以外，也增加了幾個同樣對時間序列優化的查詢語法，搭配前面提的儲存架構可以優化對時間序列資料的效率。
