Edit an SQLite database in your browser

ブラウザ上でSQLiteデータベースを編集

EditSQLiteの機能

サーバーもアカウントも不要な、フル機能のエディタ

手持ちのファイルを開く

SQLiteデータベース（.sqlite / .db）、MySQL、Postgres、SQLiteからの.sqlダンプ、プレーンなCSVを開けます。ファイルをドロップするか、空のデータベースから開始できます。

スプレッドシートのように編集

セルをダブルクリックして変更、行や列の追加・削除、テーブル名の変更、元に戻す・やり直しが可能です。サイドパネルには各テーブルのカラム、型、行数が表示されます。

SQLで編集も可能

手書きのコンソールでSELECT、UPDATE、DELETE、INSERTを実際のWHERE句と共に実行できます。瞬時にロードされ、オフラインでも動作し、すべての結果が説明可能です。

新しい有効なファイルをエクスポート

バイトごとに構築されたクリーンな.sqliteファイル、3つのダイアレクトのいずれかでの.sqlダンプ、またはCSVをダウンロードできます。各.sqliteファイルは公式エンジンの整合性チェックに合格します。

安全性の確保

インプレース操作ではなく、再構築する

貴重なファイルを編集する際、エディタは2つのパスのいずれかを選択します：ファイル内のバイトを変更する（高速ですが、1つのオフセットの間違いで永久に破損する可能性があります）か、保存時にファイル全体を再構築するかのどちらかです。EditSQLiteは常に再構築を行います。元のファイルは一度だけ読み込まれ、書き込みは行われません。編集内容はタブ内のワーキングコピーに保存され、エクスポート時には当社のSQLiteライターがモデル全体（すべてのページを再配置し、すべてのオフセットを再計算）に適用します。そして、その結果を外部標準に準拠させます。公式SQLiteエンジンのPRAGMA integrity_checkが当社の出力でパスし、エンジンは当社のビルドしたファイルに自身の行を喜んで挿入します。破損は何かを触ることで発生しますが、当社は何も触りません。

内部構造

4つの小さなピース、すべて手書き

1. リーダー — SQLiteのbツリー、varint、オーバーフローチェーンを、値ごとに解析し、扱いにくいファイルでリファレンスエンジンと比較してチェックします。
2. ダンプパーサー — mysqldump、pg_dump、sqlite3の出力を、各ダイアレクトのエスケープとCOPYブロックを実際のツールが書き込む方法で処理します。
3. コンソールエンジン — コンパクトなSQLインタープリタ（4つのステートメント、正直なWHERE句）をゼロから構築しました。瞬時のロード、予測可能な動作、エディタのデフォルトです。より重い読み取り専用分析（JOIN、GROUP BY、集計、サブクエリ）は、実際のSQLiteエンジンに委譲され、クエリが必要な場合にのみ呼び出されます。
4. ライター — レコードのエンコード、ページのパッキング、ツリーのスタッキング、ヘッダーのスタンプ：エクスポートが認定されたと呼べるようにする部分です。

限界

後から発見するのではなく、事前に明記

• インデックス、ビュー、トリガーは再作成スクリプトとして残します — ここで編集されるのはデータであり、古いインデックスは欠落しているものより悪いです。
• コンソールSQLは4つの手書き動詞（瞬時、オフライン）で編集します。JOIN、GROUP BY、集計、サブクエリは、初めて使用される際に実際のSQLiteエンジンを呼び出します — 読み取り専用なので、分析がデータを書き換えることはありません。
• スキーマパネルは、ライターがクリーンに再生成できる編集のみを提供します（テーブル名の変更、カラムの追加/名前変更/削除、ライブ行数） — このエディタは制約ではなく値をモデル化するためです。宣言された型はソースDDLが保持していた場所を示し、それ以外の場合はデータからアフィニティが読み取られ、外部キーとCHECK制約は半編集ではなく設定から外されます。
• 約4KBを超える行とブラウザメモリを超えるデータベースは、名前で拒否されます — オーバーフローページ書き込みはまだ構築されていません。
• BLOBはすべてのエクスポートでそのまま通過しますが、グリッドでは編集できません — Hex編集は別のツールです。

EditSQLiteは、ある午後に立ち往生したことから始まりました。数年前にポスドクが作成したSQLiteファイルである研究所の標本カタログで、数百行を修正する必要がありましたが、唯一許可された方法は、古いサーバーに接続されたWebフォームで、1ページあたり1行ずつでした。より高速なオプションはすべて、カタログ全体を誰か他の人のクラウドにアップロードすることを求めていました。私が望んだことは明白であり、珍しいことが判明しました：ファイルを開き、スプレッドシートのようにセルを修正し、クリーンなコピーを保存すること。データは建物を離れることなく。そこで、リーダー、ライター、そして小さな正直なSQLエンジンがすべてここで実行されるように構築されました。修正は午後に完了し、ファイルは部屋から出ず、ツールは残りました。

— EditSQLiteのエンジニアより

人々が尋ねる質問

実際に入ってくるもの

データベースの唯一のコピーを信頼できますか？

設計により、元のファイルは書き込まれず、すべてのエクスポートは新しいファイルになりますが、正直な答えは「コピーを保持してください」です。作業をチェックするのではなく、信頼するように求めるツールは、唯一のコピーを保持すべきではありません。このツールも同様です。

エクスポートした.sqliteが小さくなったのはなぜですか？

再構築では、フリーリストページ、断片化、残りのインデックスツリーなしで、ライブデータのみが書き込まれます。そのため、よく使用されたデータベースは、到着時よりも小さくエクスポートされることがよくあります。行は同じでページはタイトになります。整合性チェックがその証拠です。ページごとに処理された1つのファイル。

WHEREなしのUPDATEですべての行が変更されました！

SQLは常にそうしてきたように、そして元に戻す機能があるので、心配いりません。コンソールはすべての変更の前にチェックポイントを作成します。ここでは1回のクリックで済みますが、本番サーバーでは通常、もっと長い物語になります。安全な場所で学ぶことを検討してください。何が起こったのか、そして2つの戻り方。

MySQLやPostgresサーバーを直接編集できますか？

いいえ — ブラウザはそれらのワイヤープロトコルを話すことができず、正直に言うべきではありません。ワークフローは次のとおりです：テーブルをダンプ（1コマンド）、ここで編集、ダイアレクトダンプをエクスポート、再度ロードします。ファイルがインターフェースであり、認証情報はあなたのものです。

フォーマット間の変換

同じツールで、ジョブを指す — すべてデバイス上で、何もアップロードされません

ビルドノート

エディタの内部動作に関する長めの記事

WHEREなしのUPDATEですべての行が変更されました 1つの行が意図されていたのに250行が変更されました：SQLがそうする理由、ここに戻る2つの方法、そしてそれを止める習慣。2026年10月19日 エクスポートされたデータベースが小さくなる理由 1.8MB入力、274KB出力、すべての行はそのまま：スペースがどこに行ったのか、ページごとに、そしてあなた自身のファイルをチェックするための3つのコマンド。2026年9月29日 データベースを手書きする レコード、ページ、ツリー、そして1つのオフバイワンエラーがbツリー全体を間違った方向に向けました — 公式エンジンが承認するライターの構築。2026年7月5日 インプレース操作ではなく、再構築する 安全な編集が元のファイルを決して触らない理由 — 破損ファイルによる傷跡を伴うアーキテクチャ論争。2026年7月5日 4つのステートメントで十分 SELECT、UPDATE、DELETE、INSERT — 手書きのミニSQLエンジンがカバーするもの、拒否するもの、そして静かに教えるもの。2026年7月5日