#postgres

SupabaseがTursoを買収すると発表した。単なる企業再編に見えるかもしれないが、背景にあるのは「AIエージェントが大量のデータベースを、ものすごい勢いで作る時代」にどう備えるかという話だ。この記事は、そのインフラの変化を先回りして進めようとする動きとして読むと分かりやすい。既存ユーザーへの影響は小さいとされている一方で、SupabaseとTursoの組み合わせは、SQLiteからPostgresまでをまたぐ新しい道筋を作ろうとしている。 Supabaseは、Tursoを買収して自社に迎え入れると発表した。発表したのは2026年10月2日で、SupabaseのCEO兼共同創業者であるPaul Copplestoneが説明している。彼によれば、AIによって開発者は膨大な量のソフトウェアを作れるようになり、その結果としてエージェントがプロトタイプ、試作、ダッシュボード、アプリのために、何百万ものデータベースを立ち上げる状況がすでに起きているという。これまでのデータベース基盤では、その規模と使われ方に十分合っていないので、インフラを進化させる必要がある、というのが今回の出発点だ。 Su

Postgresで日時を扱うとき、`AT TIME ZONE 'UTC'` は便利そうに見えます。ですが、実際には「UTCに直す」という単純な処理ではなく、型そのものを変えてしまうので、思い込みのまま使うと結果がずれます。元記事はこの勘違いがどこで起きるのかを丁寧に示し、さらに一度だけで済ませず、場合によっては同じ指定を二回繰り返す必要がある理由まで触れています。日時バグは後から見つけにくく、しかも小さな違いが請求、集計、検索条件にそのまま効くので、かなり実務的な話です。 元記事の出発点は、`AT TIME ZONE 'UTC'` という書き方が多くの人の想像と違う動きをする、という指摘です。Postgres では `timestamptz` と `timestamp` が別物で、前者はタイムゾーン込みの時刻、後者はタイムゾーンを持たないただの日時です。ところが `AT TIME ZONE 'UTC'` を `timestamptz` に使うと、単に「UTCにした文字列が返る」のではなく、`timestamptz` から `timestamp` に型が変わります。元記事はここを最重要ポ

PlanetScaleが、Postgres向けの全文検索拡張「TIN」をGAとして公開した。検索エンジンというと専用プロダクトを思い浮かべがちだが、今回の話は「Postgresの中でどこまで実用的な全文検索をやれるのか」に踏み込んでいる。しかも単なる追加機能ではなく、更新が続く本番DBで検索を走らせる前提にかなり強く寄せているのが面白い。この記事では、その主張とベンチマークの見せ方がかなりはっきりしている。 PlanetScaleは、顧客から最もよく求められるPostgres機能のひとつが全文検索だとして、TINを発表した。TINは “Text INdex” の略で、PostgresとNekiの両方で使える全文検索拡張としてGA扱いになっている。使い方は素直で、`CREATE INDEX ... USING tin(...)` でインデックスを作り、`==>` 演算子で検索する。元記事では、商品説明から「stretch denim jeans」を含む上位10件を返す例、メール本文から特定の語を含む文書を拾う例、写真のタグの件数を数える例が示されていた。 PlanetScaleがTINに

Postgres のクエリオプティマイザは本当に賢いのか。Rohan Bansal の記事は、その問いに対して小さな open-weights モデルを使ってかなり挑んだ実験を紹介している。題材は SQL の join order と実行計画で、しかも単なるベンチマーク比較ではなく、reinforcement learning まで使ってモデルを後から鍛えたという点が面白い。データベースの内部で何が起きているのかが分かるだけでなく、LLM を「文章生成」以外にどう使うかの実例にもなっている。 記事の中心は、4Bサイズの Qwen モデルを後学習させて、Postgres のデフォルトより速い query plan を出させた、という実験だ。筆者はまず、クエリオプティマイザが何をしているのかを、IMDb データセットの例で説明する。`title`、`movie_companies`、`company_name` などのテーブルを結合して「2000年代に作品を出した日本企業はどこか」を調べるような SQL を考えると、同じ結果にたどり着くにしても join の順序や join algorit

PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。 Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。 PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード

Databricksのこの記事は、Postgresを土台にしたサーバーレスDB「Lakebase」と、その先にある「LTAP」という考え方を紹介しています。 話がかなり技術寄りなので、最初は「何のことだ？」となるかもしれません。でも中身はわりとシンプルで、ひと言でいえばデータベースの“保存のしかた”を根っこから見直そうという話です。 いま多くのデータベースは、書き込みログも実データも、だいたい1台のマシンの中で抱え込んでいます。この記事はそこを「そもそも古くないか？」と疑い、クラウド時代に合う形へ組み替えています。ここがかなり面白い。 しかも単なる理想論ではなく、書き込みの安全性、読み取りの拡張、障害対策、分析処理との干渉まで一気に整理しているのがポイントです。 伝統的なデータベースは、WAL（書き込みログ）と data files（実データ）を1台のマシンに持つ「monolith」になりがち その構造だと、データ消失のリスク、read replica の高コスト化、分析処理による遅延が起きやすい Lakebase は Postgres の compute を stat

この記事は、「durable execution（壊れにくい実行）」には、必ずしも巨大な基盤は要らないと主張しています。 DBOS が「Postgres があれば十分」と言った流れに対して、Obelisk は「もっと進めて、SQLite でも多くのケースで十分では？」と提案しています。 重要なのは 計算処理そのもの ではなく、workflow の状態を安全に残すこと だ、という考え方です。 SQLite は単体で transactional な永続性を持てるので、余計な DB サービスを増やさずに済みます。 Litestream を使えば、SQLite の変更を S3 互換の object storage に非同期でバックアップできます。 ただしこれは高可用性の共有DBの代わりではなく、多少の遅延や一部データ喪失の可能性を許容する設計です。 AI agents や実験的な workflow には、Postgres より SQLite のほうがシンプルで相性がいい場面が多い、というのがこの記事の見立てです。 「durable workflows を作るのに、最初から大げさ

DBOSは、Postgresを使って durable execution（途中で落ちても再開できる実行方式）を実現しよう、という考え方を紹介している 従来は Temporal や Airflow、AWS Step Functions のような外部の orchestrator（司令塔）がワークフローを管理する DBOSの記事は、「そもそもデータベースが司令塔になればよくない？」という発想を押し出している Postgresに進捗を checkpoint（保存）すれば、クラッシュしても最後の保存地点から再開できる 可観測性（observability）は、PostgresのテーブルをSQLで見るだけでかなり強力に実現できる 既存システムがすでにPostgresを使っているなら、新しい中枢システムを増やさずに済むのが大きなメリット まず、ここがいちばん大事です。 durable execution は、ざっくり言うと「処理の途中経過をちゃんと保存しておいて、落ちても続きからやり直せる仕組み」のことです。 ゲームでいうセーブポイントみたいな