Objectify

Every new product starts with the same fortnight of work. A users table. Sessions, password resets, email verification. An upload path that puts a file somewhere sensible and hands back a URL you can safely show a stranger. An audit log, for the day somebody asks who changed that record and when. None of it is difficult. All of it is slow, and you write it again on the next project, slightly differently, with a fresh set of small bugs in it.

Why it exists

Objectify is that fortnight, done once and hosted. You describe your object types in a schema designer, up to 22 column data types with directed associations between any two of them, and you have a versioned REST API over them immediately. The first day of a project then goes on the part that makes the project different, rather than on the parts every project shares.

It is aimed at developers and small technical teams who do not want to operate infrastructure. The use cases the product names are multi-tenant B2B software, mobile and web app backends, internal tools and dashboards, prototypes, marketplaces, and products with an AI feature attached to a data store. There are 95 prebuilt industry schema templates covering sectors from healthcare to hospitality and retail, and they exist for one reason: a shape you can argue with beats an empty page.

The alternative is a conventional server stack, and we keep one of those in the studio as well. Starterflare is a NestJS platform codebase that has never been released, and the reason it stalled is worth knowing before you pick a side. A stack with a database, a cache, a message broker and a search engine in it bills every hour whether anybody uses the product or not. We sat down and worked out what four stateful services cost at rest instead of arguing about it. Objectify sits on the other side of that trade, and a free tier is only affordable because of where it sits.

How it works

A request carries a scoped API key. The key resolves to a tenant, the tenant resolves to a database, and the write lands there. The middle step is the interesting one, because tenant data is not in one database but spread across ten, and a Durable Object holds the directory that maps one to the other.

POST /v1/objects/invoice
  -> resolve API key, scopes and tenant
  -> TenantDirectory: tenant 4f21 lives on shard 7   (one request at a time)
  -> D1 shard 7: insert row, bump version, write audit entry
  -> queue object-events: indexes, webhooks, realtime fan-out
  -> 201, with the object and its version

Reads come back through the same routing. Search supports eq, in, gt, gte, lt, lte and exists, with pagination by cursor only, never by offset. Batch reads take up to 100 records in a call and batch updates up to 50. Deletes are soft, every object keeps a version history, and writes use optimistic versioning so two clients editing the same record produce a conflict rather than a silent overwrite.

Around the store sit the pieces you would otherwise build. Authentication covers passwords, magic links, OAuth providers, phone one-time codes, anonymous sessions and TOTP multi-factor, with JWTs, refresh tokens, verification and reset flows. Files go to object storage with direct or presigned uploads, signed URLs, variants, folders, versions and a cleanup job for uploads that were started and abandoned. The AI endpoints cover embeddings, vector search and indexing, chat and generation, moderation and image description. Webhooks fire with retries and a delivery log you can read when a customer says nothing arrived. Access is governed by row level policies, keys you can rotate, and a sliding window rate limit per tenant. The dashboard wraps all of it with a data explorer, a SQL editor, audit logs, import and export.

The decision that shaped it

Everything above rests on the tenancy model, and the tenancy model was chosen on day one. The obvious design is one large database with a tenant column on every table. It takes an afternoon and it makes isolation a rule that has to be reapplied by every person who ever writes a query, including whoever is answering a support ticket in a hurry on a Friday. Get it wrong once and a customer sees another customer's records.

A fixed pool of ten databases turns that rule into routing. You open a database and the other tenants' rows are not there to be selected by accident. New tenants go to the least loaded shard, and a tenant can be moved between shards while the service is running: hold the writes, copy, switch the mapping, verify, clean up the old copy, release. The full argument, including why the lock has to come first and why cleanup has to come last, is in when many small databases beat one big one.

Here is what it costs. Every schema change is now a distributed operation with partial failure: you will apply a migration to seven databases and have to think carefully about the other three. No single query answers a question about all customers, so anything that looks like a product metric means fanning out or keeping counters. Backups, monitoring and connection handling all multiply by ten. And ten is a compromise rather than a principle, chosen because ten is a number a person can watch a migration across at three in the morning and one thousand is not.

The same question got a different answer in Consonas, where each customer organisation gets a database of its own. That product holds other companies' client lists and sells to buyers who ask about isolation before they ask about features, so the migration fan-out is worth paying. Objectify has a free tier and self-serve sign-up, which means the shard count has to stay small enough to operate.

The second choice is quieter and shows up more often. Search indexes, including the full-text index, are maintained asynchronously from a queue rather than on the write path. Writes stay quick, and the cost is that a search result can trail the write that caused it by a moment. If you need read-after-write on search, this is the wrong store, and it is better to know that from a portfolio page than from a bug report.

Where it stands today

Live, open to self-serve sign-up, four plans in sterling billed monthly or annually.

Plan	Monthly	Tenants	Records	Storage	Auth users
Free	£0	1	25,000	500 MB	100
Starter	£15	3	250,000	5 GB	1,000
Pro	£39	10	2,000,000	25 GB	10,000
Business	£99	unlimited	20,000,000	100 GB	100,000

Annual billing brings those to £12, £31 and £79 a month, and a launch discount currently halves the paid prices automatically. Whether that discount is permanent is genuinely unresolved: the FAQ says early adopters keep it while the subscription stays active, and no end date for the launch period is published. AI and realtime are limited to the top two tiers. Webhooks are off on the free plan.

Now the parts that do not flatter us. There are no customer numbers, no revenue figures and no case studies, because there are none to publish. The headline statistics on the marketing pages, edge latency under 30ms, a 99.9 percent uptime target, 300 or more locations, are claims presented without measurement and there is no status page standing behind them. The About page mentions TypeScript and Python SDKs and a CLI; no package names appear anywhere in the shipped documentation and no SDK source exists, so treat the REST API and the OpenAPI 3.1 document as the interfaces that actually exist. Partition mode for very large tenants is in the schema and switched off, so a tenant lives on one shard and inherits that database's ceiling. The shipped dashboard contains around twenty route chunks, covering workflows, roles, scheduled jobs, reports, governance and more, that we cannot vouch for from source, so they are not in the feature list. Stripe price identifiers are read from the environment at runtime, which means paid checkout completing end to end in production is not something we have observed rather than something we can promise.

What this says about how we work

Running this ourselves is why the advice we give clients is not free of consequences to us. A free tier with open sign-up is an unusually honest teacher: it puts real strangers with real data on the architecture and shows you within weeks which early decisions were cheap and which were structural.

The pattern we take into client work is the one visible above. Make the two or three decisions that are painful to reverse with full attention and in writing, then keep everything built on top of them as plain as it can be, and leave the clever version unbuilt until something forces it. Partition mode is not built. Ranked search is not built. The directory and the sharding are, because those are the ones you cannot bolt on afterwards. If you want the same treatment applied to a backend of your own, how we scope and price that work is set out plainly, including where we would tell you not to build.