[rm-sled] Remove the Sled database engine

8 files changed, 13 insertions, 41 deletions

diff --git a/doc/api/garage-admin-v1.yml b/doc/api/garage-admin-v1.yml
index fd78feb1..1ea77b2e 100644
--- a/doc/api/garage-admin-v1.yml
+++ b/doc/api/garage-admin-v1.yml
@@ -98,7 +98,6 @@ paths:
                       type: string
                     example:
                       - "k2v"
-                      - "sled"
                       - "lmdb"
                       - "sqlite"
                       - "consul-discovery"
diff --git a/doc/book/connect/apps/index.md b/doc/book/connect/apps/index.md
index 5def3851..9a678275 100644
--- a/doc/book/connect/apps/index.md
+++ b/doc/book/connect/apps/index.md
@@ -292,7 +292,7 @@ with average object size ranging from 50 KB to 150 KB.
 As such, your Garage cluster should be configured appropriately for good performance:
 
 - use Garage v0.8.0 or higher with the [LMDB database engine](@documentation/reference-manual/configuration.md#db-engine-since-v0-8-0).
-  With the default Sled database engine, your database could quickly end up taking tens of GB of disk space.
+  Older versions of Garage used the Sled database engine which had issues, such as databases quickly ending up taking tens of GB of disk space.
 - the Garage database should be stored on a SSD
 
 ### Creating your bucket
diff --git a/doc/book/cookbook/from-source.md b/doc/book/cookbook/from-source.md
index bacf93ab..f7fd17ce 100644
--- a/doc/book/cookbook/from-source.md
+++ b/doc/book/cookbook/from-source.md
@@ -90,6 +90,5 @@ The following feature flags are available in v0.8.0:
 | `kubernetes-discovery` | optional | Enable automatic registration and discovery<br>of cluster nodes through the Kubernetes API |
 | `metrics` | *by default* | Enable collection of metrics in Prometheus format on the admin API |
 | `telemetry-otlp` | optional | Enable collection of execution traces using OpenTelemetry |
-| `sled` | *by default* | Enable using Sled to store Garage's metadata |
-| `lmdb` | optional | Enable using LMDB to store Garage's metadata |
+| `lmdb` | *by default* | Enable using LMDB to store Garage's metadata |
 | `sqlite` | optional | Enable using Sqlite3 to store Garage's metadata |
diff --git a/doc/book/cookbook/real-world.md b/doc/book/cookbook/real-world.md
index cb10b550..30be4907 100644
--- a/doc/book/cookbook/real-world.md
+++ b/doc/book/cookbook/real-world.md
@@ -70,9 +70,8 @@ to store 2 TB of data in total.
 
 - If you only have an HDD and no SSD, it's fine to put your metadata alongside the data
   on the same drive. Having lots of RAM for your kernel to cache the metadata will
-  help a lot with performance.  Make sure to use the LMDB database engine,
-  instead of Sled, which suffers from quite bad performance degradation on HDDs.
-  Sled is still the default for legacy reasons, but is not recommended anymore.
+  help a lot with performance.  The default LMDB database engine is the most tested
+  and has good performance.
 
 - For the metadata storage, Garage does not do checksumming and integrity
   verification on its own. If you are afraid of bitrot/data corruption,
diff --git a/doc/book/design/internals.md b/doc/book/design/internals.md
index cefb7acc..8e3c214e 100644
--- a/doc/book/design/internals.md
+++ b/doc/book/design/internals.md
@@ -97,7 +97,7 @@ delete a tombstone, the following condition has to be met:
   superseeded by the tombstone. This ensures that deleting the tombstone is
   safe and that no deleted value will come back in the system.
 
-Garage makes use of Sled's atomic operations (such as compare-and-swap and
+Garage uses atomic database operations (such as compare-and-swap and
 transactions) to ensure that only tombstones that have been correctly
 propagated to other nodes are ever deleted from the local entry tree.
 
diff --git a/doc/book/reference-manual/configuration.md b/doc/book/reference-manual/configuration.md
index 580e9fbc..4df2d0df 100644
--- a/doc/book/reference-manual/configuration.md
+++ b/doc/book/reference-manual/configuration.md
@@ -20,8 +20,6 @@ db_engine = "lmdb"
 
 block_size = "1M"
 
-sled_cache_capacity = "128MiB"
-sled_flush_every_ms = 2000
 lmdb_map_size = "1T"
 
 compression_level = 1
@@ -96,9 +94,7 @@ Top-level configuration options:
 [`rpc_bind_addr`](#rpc_bind_addr),
 [`rpc_bind_outgoing`](#rpc_bind_outgoing),
 [`rpc_public_addr`](#rpc_public_addr),
-[`rpc_secret`/`rpc_secret_file`](#rpc_secret),
-[`sled_cache_capacity`](#sled_cache_capacity),
-[`sled_flush_every_ms`](#sled_flush_every_ms).
+[`rpc_secret`/`rpc_secret_file`](#rpc_secret).
 
 The `[consul_discovery]` section:
 [`api`](#consul_api),
@@ -271,20 +267,16 @@ Since `v0.8.0`, Garage can use alternative storage backends as follows:
 
 | DB engine | `db_engine` value | Database path |
 | --------- | ----------------- | ------------- |
-| [LMDB](https://www.lmdb.tech) (default since `v0.9.0`) | `"lmdb"` | `<metadata_dir>/db.lmdb/` |
-| [Sled](https://sled.rs) (default up to `v0.8.0`) | `"sled"` | `<metadata_dir>/db/` |
-| [Sqlite](https://sqlite.org) | `"sqlite"` | `<metadata_dir>/db.sqlite` |
+| [LMDB](https://www.lmdb.tech) (since `v0.8.0`, default since `v0.9.0`) | `"lmdb"` | `<metadata_dir>/db.lmdb/` |
+| [Sqlite](https://sqlite.org) (since `v0.8.0`) | `"sqlite"` | `<metadata_dir>/db.sqlite` |
+| [Sled](https://sled.rs) (old default, removed since `v1.0`) | `"sled"` | `<metadata_dir>/db/` |
 
-Sled was the only database engine up to Garage v0.7.0. Performance issues and
-API limitations of Sled prompted the addition of alternative engines in v0.8.0.
-Since v0.9.0, LMDB is the default engine instead of Sled, and Sled is
-deprecated. We plan to remove Sled in Garage v1.0.
+Sled was supported until Garage v0.9.x, and was removed in Garage v1.0.
+You can still use an older binary of Garage (e.g. v0.9.3) to migrate
+old Sled metadata databases to another engine.
 
 Performance characteristics of the different DB engines are as follows:
 
-- Sled: tends to produce large data files and also has performance issues,
-  especially when the metadata folder is on a traditional HDD and not on SSD.
-
 - LMDB: the recommended database engine on 64-bit systems, much more
   space-efficient and slightly faster. Note that the data format of LMDB is not
   portable between architectures, so for instance the Garage database of an
@@ -333,7 +325,6 @@ Here is how this option impacts the different database engines:
 
 | Database | `metadata_fsync = false` (default) | `metadata_fsync = true`       |
 |----------|------------------------------------|-------------------------------|
-| Sled     | default options                    | *unsupported*                 |
 | Sqlite   | `PRAGMA synchronous = OFF`         | `PRAGMA synchronous = NORMAL` |
 | LMDB     | `MDB_NOMETASYNC` + `MDB_NOSYNC`    | `MDB_NOMETASYNC`              |
 
@@ -367,21 +358,6 @@ files will remain available. This however means that chunks from existing files
 will not be deduplicated with chunks from newly uploaded files, meaning you
 might use more storage space that is optimally possible.
 
-#### `sled_cache_capacity` {#sled_cache_capacity}
-
-This parameter can be used to tune the capacity of the cache used by
-[sled](https://sled.rs), the database Garage uses internally to store metadata.
-Tune this to fit the RAM you wish to make available to your Garage instance.
-This value has a conservative default (128MB) so that Garage doesn't use too much
-RAM by default, but feel free to increase this for higher performance.
-
-#### `sled_flush_every_ms` {#sled_flush_every_ms}
-
-This parameters can be used to tune the flushing interval of sled.
-Increase this if sled is thrashing your SSD, at the risk of losing more data in case
-of a power outage (though this should not matter much as data is replicated on other
-nodes). The default value, 2000ms, should be appropriate for most use cases.
-
 #### `lmdb_map_size` {#lmdb_map_size}
 
 This parameters can be used to set the map size used by LMDB,
diff --git a/doc/drafts/admin-api.md b/doc/drafts/admin-api.md
index e7851ab1..40c82f5a 100644
--- a/doc/drafts/admin-api.md
+++ b/doc/drafts/admin-api.md
@@ -73,7 +73,6 @@ Example response body:
   "garageVersion": "v0.10.0",
   "garageFeatures": [
     "k2v",
-    "sled",
     "lmdb",
     "sqlite",
     "metrics",
diff --git a/doc/drafts/k2v-spec.md b/doc/drafts/k2v-spec.md
index faa1a247..3956fa31 100644
--- a/doc/drafts/k2v-spec.md
+++ b/doc/drafts/k2v-spec.md
@@ -146,7 +146,7 @@ in a bucket, as the partition key becomes the sort key in the index.
 How indexing works:
 
 - Each node keeps a local count of how many items it stores for each partition,
-  in a local Sled tree that is updated atomically when an item is modified.
+  in a local database tree that is updated atomically when an item is modified.
 - These local counters are asynchronously stored in the index table which is
   a regular Garage table spread in the network. Counters are stored as LWW values,
   so basically the final table will have the following structure: