Vector search and geospatial data in your Salus databases

The database you provision with your app can now do more of the work your app needs. PostgreSQL databases on Salus support two of the most requested extensions, pgvector and PostGIS, so AI features and location-aware features no longer mean standing up a second, specialised data store alongside the one you already have. And as more teams in your company start building, you can now define how their apps get built and shipped once, for the whole organization.

Embeddings live next to the data they describe

With pgvector, your database can store vector embeddings and search them by similarity. That is the building block behind semantic search, recommendations, and retrieval-augmented generation: the pattern where an AI feature looks up the most relevant records before it answers.

Keeping those embeddings in the same database as your application data means one connection string, one backup story and one place to govern access. You can join a similarity search against your own tables in a single query, instead of syncing records out to a separate vector service and keeping the two in step.

Location-aware apps without a separate GIS stack

PostGIS adds geographic types and spatial queries to PostgreSQL. Store points, routes and boundaries, then ask the questions location features depend on: what is nearby, what falls inside this area, how far apart two places are.

If you are building delivery tracking, field service tools, store finders or anything that puts data on a map, the spatial engine now comes with the database you already provision on Salus.

Both, side by side

The extensions work independently and together. A single database can run pgvector and PostGIS at once, so an app that needs “find similar listings near me” can answer it in one place.

Set your pipeline configuration once, for the whole organization

Until now, pipeline configuration lived with each project. That works for a handful of services, but it scales badly: every new project is another copy to set up, and every change is a hunt through each one to make it match. The more people building, the more those copies drift apart.

Organization level pipeline configuration moves that decision up a level. You set it once for your organization, and it becomes the starting point for the projects inside it. A new project picks up the way your organization builds from day one, rather than whatever its creator remembered to configure.

• Less repetition — configure your pipelines once rather than once per project.
• Change it in one place — update the organization’s configuration and you’re not chasing the same edit across every project.
• Fewer surprises between teams — builders across the organization ship through the same setup, so a deploy from one team behaves like a deploy from another.

---

As always, these changes are live now and require no action on your part. We’d love to hear what you think. Your feedback shapes what we build next.