Category: Learning

Brendan Tierney continues a series on vector databases:

In this post on Vector Databases, I’ll look at the main components:

• Vector Embedding Models. What they do and what they create.
• Vectors. What they represent, and why they have different sizes.
• Vector Search. An overview of what a Vector Search will do. A more detailed version of this is in a separate post.
• Vector Search Process. It’s a multi-step process and some care is needed.

Read on for more about these terms and ideas.

Comments closed

Brendan Tierney gives us an overview of vector databases:

A Vector Database is a specialized database designed to efficiently store, search, and retrieve high-dimensional vectors, which are often used to represent complex data like images, text, or audio. Vector Databases handle the growing need for managing unstructured and semi-structured data generated by AI models, particularly in applications such as recommendation systems, similarity search, and natural language processing. By enabling fast and scalable operations on vector embeddings, vector databases play a crucial role in unlocking the power of modern AI and machine learning applications.

It’s interesting to see this pop up as a standalone database type (e.g., chromadb), though we’re also seeing some existing players like Postgres support vector database functionality via extension.

Comments closed

Grant Fritchey needs you:

Hello all! This post is nothing but a simple request. Please, if you have a few spare minutes, meander on over to this link and fill out the State of the Database Landscape Survey for 2024. Yeah, it’s for Redgate Software, my employer. But, really, it’s for everyone. Why is it for everyone? Because, every time we do one of these surveys, we don’t sit on the data, we share it. Here are the results from the 2023 survey, published earlier this year.

Yeah, but, I hear you opining, what does this really do for me? Well, let’s talk about it.

Check out the benefits and also fill out the survey.

Comments closed

Brent Ozar shares some thoughts:

I’m not talking just about Microsoft SQL Server specifically here, nor T-SQL. Let’s zoom out a little and think bigger picture for a second: is the SQL language itself a problem?

Sometimes when I talk to client developers, they gripe about the antiquated language.

Brent goes on to list some common complaints with SQL in general and explains why there isn’t a better solution.

I should note that he also summarizes Feasel’s Law near the end of the post:

Remember when NoSQL came out, and everybody was all “databases r doomd”? And remember what business users said when they wanted to run their reports? NoSQL persistence layers pretty quickly changed their tune, saying, “Oh, well, uh, we meant Not Only SQL, that’s what we meant,” as they struggled to quickly slap in SQL compatibility. Even MongoDB, king of NoSQL, implemented SQL support.

Comments closed

Steve Jones works with Steve Rezhener:

Steve Rezhener put together a survey for what topics you’d like to learn about. A few others, including myself, gave him feedback and he’s published this for people to use. It was intended for SQL Saturday organizers and speakers, but it can work well for anyone producing information. I’ve created some shortlinks at SQL Saturday that you can use to take the survey and see the results.

• https://sqlsaturday.com/survey
• https://sqlsaturday.com/surveyresult

I’m promoting this because when I initially got the e-mail for it, I thought it was spam. With enough responses, this may help organizers focus in on specific topics for events, at least to some extent.

Comments closed

Robert Haas talks about a development challenge:

Hacking on PostgreSQL is really hard. I think a lot of people would agree with this statement, not all for the same reasons. Some might point to the character of discourse on the mailing list, others to the shortage of patch reviewers, and others still to the difficulty of getting the attention of a committer, or of feeling like a hostage to some committer’s whimsy. All of these are problems, but today I want to focus on the purely technical aspect of the problem: the extreme difficulty of writing reasonably correct patches.

Read on for Robert’s experience developing incremental backups in Postgres. In fairness, I think this is true of any complex system which becomes mission-critical. It’s really easy to develop in low-risk, limited-code, greenfield environments. As you change each of those properties, development gets considerably more challenging, even if people are doing the right things the right way and checking ego at the door.

Comments closed