Collections and Schema

## What a collection is Weaviate's top-level container is a **collection** (the REST schema and older material call it a *class*). A collection holds objects of one kind and every object in it shares one definition: the same property declarations, the same vector index and distance metric, the same inverted-index settings, the same replication factor and the same multi-tenancy setting. That makes it closer to a relational table than to a bare vector index — the schema is a server-side artifact you can read back, not something your application keeps in its head. An object inside a collection is three things at once: a UUID, a set of typed properties (the JSON payload), and one or more vectors. Weaviate stores the properties in an inverted index so they can be filtered and keyword-searched, and the vector in a vector index so it can be searched by similarity. The collection definition is what configures both halves. ## Creating one with the v4 Python client `client.collections.create(...)` is the single entry point. The minimum is a name; in practice you pass `properties=[...]`, each one a `Property(name=..., data_type=...)` from `weaviate.classes.config`. Two naming rules bite newcomers: Weaviate capitalises the first letter of a collection name, so `article` and `Article` are the same collection, and property names must start with a lowercase letter and stay GraphQL-safe. ## Properties and data types The `DataType` enum covers `TEXT`, `INT`, `NUMBER`, `BOOL`, `DATE`, `UUID`, `GEO_COORDINATES`, `BLOB`, `OBJECT` and the corresponding `_ARRAY` variants. The type is not decoration: it decides what the inverted index can do with the value. A `TEXT` property is tokenised and can be BM25-searched; an `INT`, `NUMBER` or `DATE` property supports range comparisons; a `UUID` is stored compactly. Getting `INT` versus `NUMBER` wrong, or storing a timestamp as `TEXT`, quietly costs you range filtering later. `Property` also carries indexing switches — notably `index_filterable` and `index_searchable`, and `tokenization` for text — that let you skip index building for properties you never query on, trading query ability for faster imports and less disk. Vectorisation flags on a property control whether its text feeds the embedding, which is the vectoriser module's concern rather than the schema's. ## What else the definition holds Beyond properties, `collections.create` accepts: the vector index configuration (`Configure.VectorIndex.hnsw()`, `.flat()` or `.dynamic()`) and its distance metric; inverted-index configuration such as BM25 parameters, stopwords and whether timestamps and null states are indexed; `references=[ReferenceProperty(...)]` for links to other collections; `replication_config=Configure.replication(factor=...)`; and `multi_tenancy_config=Configure.multi_tenancy(...)`. All of these are per-collection, which is exactly why the create call carries so much weight — several of these choices cannot be changed afterwards. ## Lifecycle `client.collections.exists("Article")` checks existence, `client.collections.list_all()` enumerates definitions, `client.collections.get("Article")` returns the handle you use for data and queries, and `client.collections.delete("Article")` destroys the definition *and* all of its objects with no undo. On the handle, `collection.config.get()` reads the current definition back, `collection.config.add_property(...)` appends a property, and `collection.config.update(...)` changes the mutable settings. ## Why interviewers start here Because the collection is the unit of configuration, it is also the unit of blast radius. Filtering, hybrid search, tenant isolation, memory footprint and re-import cost are all decided by what you wrote in `collections.create`. A candidate who can describe a collection as "a typed table whose definition also pins the vector index and tenancy model" is set up for every harder Weaviate question that follows.