What does lancedb.connect() do for a local path versus an s3:// URI?

## connect is an open, not a connection `lancedb.connect(uri)` returns a `DBConnection` object, but almost nothing about it resembles a client-server database connection. There is no handshake, no authentication round trip against a LanceDB daemon, no pool to size, and no port to expose — LanceDB is embedded, so the library running inside your process *is* the database. The URI names a root location; the connection is a handle for listing, opening and creating tables under it. That single fact explains most of LanceDB's operational character. ## A local path Given `./lance` or an absolute directory, LanceDB creates the directory if it is missing and returns immediately. Tables you create appear as subdirectories named `<table>.lance`, each a Lance dataset: columnar data files, a versions/manifest area recording each committed version, index files, and deletion files. `db.table_names()` is a directory listing; `db.open_table(name)` opens the dataset's current manifest. You can copy or rsync the whole directory to move the database, and you can inspect it with ordinary file tools — there is no opaque server state anywhere else. ## An object-storage URI Pass `s3://bucket/prefix` (also `gs://` and `az://`) and the identical layout is written to object storage. Credentials and region do not go in the URI; they go in `storage_options`, for example `lancedb.connect("s3://bucket/prefix", storage_options={"region": "us-east-1"})`, which also carries things like a custom endpoint for S3-compatible stores. Anything not supplied there falls back to the environment's usual credential chain. The behaviour changes even though the API does not. Object storage has high per-request latency and no cheap random small reads, so the format's design — large columnar files read with ranged GETs, metadata in manifests — is what keeps queries viable. Warm local disk gives millisecond queries; the same table on S3 from a laptop can be an order of magnitude slower, and running compute in the same region as the bucket matters more than any tuning parameter. Also note the deployment shape this unlocks: many stateless workers all pointing at one bucket, no cluster to operate. ## Consistency between processes Because each process reads the manifest it opened, a `Table` object does not automatically see versions committed by someone else. `lancedb.connect(uri, read_consistency_interval=timedelta(seconds=5))` sets how often an open table re-checks for newer versions; `timedelta(0)` checks on every operation (strongest, most metadata reads), and the default leaves the table on the version it opened until you explicitly refresh it with `checkout_latest()`. Getting this wrong produces the classic "the writer added rows but my reader still returns the old count" report. ## Writers Lance commits are versioned, and concurrent writers to the same table race to commit the next version; conflicting commits fail and must be retried, so the comfortable model is one writer per table with many readers. If you need multiple ingest processes, partition them across tables, funnel them through a single writer, or accept and handle commit retries. This is the main thing you give up by not running a server. ## Async and cloud `lancedb.connect_async(uri)` gives the async client with the same URI semantics for use inside an event loop. A `db://` URI targets LanceDB Cloud rather than storage you own, in which case an API key is supplied instead of storage credentials — the table API you write afterwards stays the same, which is the point of the uniform URI. ## What to say in an interview Summarise it as: the URI chooses where bytes live, not how you talk to the database. Local paths for development and single-node services, object storage for shared, elastic, serverless-style deployments; `storage_options` for credentials; latency and consistency, not API differences, are what actually change between them.