Database search is okay, at best. To build awesome search experiences you need a dedicated search product.

Earlier this month we released Tigris Search in BETA and covered how it supports automatic synchronization infrastructure between Tigris Database and Tigris Search, which improves developer productivity by enabling the team to focus on shipping features and not setting up and managing search and synchronization infrastructure.

However, you may be looking to quickly enhance your application experience by adding search capabilities using existing data without waiting to migrate your database to Tigris. Or, your data may not be in a database, and it's in some other type of data store, such as S3.

Whatever the reason, the Tigris Standalone Search feature allows you to quickly add search to your existing data.

Today, we're excited to share that Tigris Search has moved into beta.

Over the coming days, we'll share more about the features available in Tigris Search. But in this post, we'd like to focus on a feature that feels magical and we believe differentiates Tigris from the competition: Tigris Database to Search automatic synchronization.

Tigris Database to Search automatic synchronization allows you to automatically create search indexes and synchronize your data from Tigris Database to Tigris Search. You don't need to spin up any new and costly infrastructure or add any complex configuration to take advantage of this. All you need to do is update your Tigris data model definitions!

Welcome to the Tigris April 2023 update!

This month saw a preview of our Vector database search, a new Tigris Astro integration, the completion of our NoSQL data modeling guides, the invention of a new technology stack called TERN, and more.

This update covers:

• 🤖 Vector search preview
• 👾 Tigris Astro integration
• 🧑‍🏫 NoSQL data modeling series complete
• 🧰 From the MERN stack to TERN
• ✨ Tigris TypeScript SDK filter syntax update (Breaking change!)
• 🚛 Data import with schema inference for both JSON and CSV
• 🦾 Web console updates
• 🤔 MongoDB vs DynamoDB vs Tigris

Choosing how your app stores and manages data is one of those foundational decisions that will impact just about every other step you take. But with so much variety, how do you make the right call?

Tigris is an open source NoSQL database and search platform that you can run in any cloud, on your own hardware, or have it managed for you via Tigris Cloud. Here we'll look at how Tigris compares both to MongoDB and DynamoDB, as well as providing an overview of some of the features and tradeoffs you'll need to consider.

Just want to see the feature comparison table? No problem, view the NoSQL database comparison table >

Astro bills itself as "the all-in-one web framework designed for speed," allowing you to "pull your content from anywhere." Their integration ecosystem helps you build performant, accessible, and SEO-friendly sites. Having built several sites with Astro, I can attest to the breadth of options to get your site up and running quickly.

But there was one noticeable gap in the ecosystem: database access. This is understandable because most Astro sites are built to be static. That's not to say you couldn't use a database with an Astro site, but it lacked the ease of use that their other integrations provide.

That's why we're excited to announce the official Tigris integration (@tigrisdata/astro) for Astro. This integration allows you to use Tigris as your database, and pull your data into your Astro site. This means you can build a static site with Astro, and use Tigris to power your content.

This is part 3 of the NoSQL Data Modeling Series. In part one of the series, we covered modeling NoSQL one-to-one relations. and in part two we explored modeling NoSQL one-to-many relations. This is the third and final post and we will dive into modeling NoSQL many-to-many relations.

We model NoSQL many-to-many relations in two ways:

1. Embeded many-to-many NoSQL data modeling
2. Many-to-many NoSQL data modeling using a joining collection

For the second example we'll use related documents and demonstrate full-text search to perform advanced queries against our data.

The MERN Stack - a web technology stack consisting of MongoDB, Express.js, React, and Node.js - was introduced around 2018 as a popular set of technologies to enable end-to-end development in JavaScript. Although the popularity of fullstack frameworks such as Next.js means that MERN isn't as popular as it once was, it is still a viable and productive choice with its decoupled architecture providing more flexibility than you'll get with a fullstack framework.

Today, I'd like to introduce the TERN (Tigris, Express.js, React, and Node.js) stack which replaces MongoDB with Tigris.

In this post, you'll learn about MERN and TERN and why you should migrate from MERN to TERN. We'll cover all the steps involved in migrating a MERN application to TERN (Tigris, Express.js, React, and Node.js); first using Tigris MongoDB compatibility to get your existing application working with Tigris instead of MongoDB without any code changes (⚠️ spoiler: it's as simple as updating the MongoDB connection string). Then, we'll make a few changes to get the application using the Tigris SDK instead of the MongoDB Node.js driver, completing the migration.

In this post, we'll show you how to use the OpenAI Embeddings API to generate embeddings for your documents and then use Tigris to index these embeddings for fast and scalable vector search.

This is a powerful combination that can be used for building semantic search applications, recommendation engines, and more.

What is vector search?​

Vector search is a type of search that uses vector representations of documents to find similar documents. Vector search is a powerful technique that can be used to find similar documents, images, and videos. Vector search is also useful for finding similar products, recommendations, and more.

Hello, and welcome to the first Tigris update. Each month we'll share product and community highlights and let you know what to look out for in the coming month.

I did a presentation at the FoundationDB Monthly Meetup. The talk is about, how building secondary indexes for a database is always about balance. A balance between a system that scales and is easy to manage and an API that is intuitive and delightful for a developer to use. Recently at Tigris Data, we have been adding secondary indexes to our database and have been working hard to achieve a good balance between scale and developer delight. Tigris is a transactional document database that runs on top of FoundationDB and is compatible with MongoDB. In this talk I cover four aspects we had to balance:1. Handling schema changes automatically in our secondary indexes so that users don't have to worry about it.

1. The trade-off between auto-indexing all fields and indexing select fields.
2. Changes we made after performance testing.
3. How we plan build indexes in the background with minimal conflicts.