DEV Community: Amro

Qdrant's free tier can be your whole database, not just your vector index

Amro — Wed, 28 Oct 2026 20:55:31 +0000

TL;DR: Qdrant isn't only a vector index. but a whole database for my usecase

I run Bastet, a dictionary of Ancient Egyptian with Arabic and English translations. The backend is a small NestJS API on Heroku. Its database was RavenDB Cloud, mostly because RavenDB embeds text for you: insert a word with an English gloss, and you can search it by meaning without ever computing a vector yourself.

That convenience cost €40 a month, which is a lot for a side project with 70,000 documents. So I looked at the usual suspects: MongoDB Atlas, Weaviate, Qdrant. My assumption was that a vector database could replace the search part of RavenDB, and I'd need something else for everything that wasn't search: category listings, admin paging, and the app's smaller collections that have nothing to do with search.

That assumption was wrong. Qdrant's free tier is now the only database the API talks to. Here's what moved, what I had to give up, and how the migration went.

What the API actually asked of its database

Before deciding anything I went through every database call in the codebase. It's worth doing; the list was shorter than I feared.

Vector search on words and sentences, in English and Arabic. The core feature.
Load by id, create, patch, delete. The admin panel.
Filter by field, such as words by category.
Paged keyword search for the admin panel, with a regex that treats the variant forms of an Arabic letter (the alef) as one letter.
Infix search (*word*) for non-English queries.
Sorting by a nested field, and by creation date.
A few plain collections with no vectors at all.

Everything in the first three groups maps directly onto Qdrant: a point's payload is the document, filters cover whereEquals and whereIn, and ids can be UUIDs, which RavenDB was already using. The last four needed compromises.

The compromises

No regex, no infix. Qdrant's full-text index matches tokens, not substrings, and there is no regex at all. I replaced both with a prefix tokenizer over a normalized copy of each word: lowercase, Arabic diacritics stripped, alef variants folded to one base letter. The query is normalized the same way, so, much like "abc" finding "ábc", the plain spelling finds the variant spelling without any regex. What I lost is matching the middle of a word: *ankh* no longer finds sankh. For a dictionary that's acceptable.

Sorting happens in code. Qdrant only orders by indexed numeric and date fields. Category lists sorted by the Egyptian word are small, so I sort them after fetching. Anything sorted by creation date works natively because I indexed it as a datetime.

One vector per meaning. A dictionary entry often has several English glosses ("to be whole; to be intact"). RavenDB embedded each one. Qdrant has multivectors for exactly this: each word stores one vector per meaning and is scored by its best match. This turned out to matter for quality; a single joined string blurs the meanings together.

Collections without vectors. The non-search collections are stored as points with an empty vector config and just a payload. It feels slightly odd, and it works fine.

Updates rewrite the whole point. RavenDB tracks changes inside a session; Qdrant doesn't. A patch loads the document, mutates it, and upserts it back, which also re-embeds it if a meaning changed. The one thing that costs is optimistic concurrency, which a single-editor admin panel doesn't need.

The migration

The whole thing is five steps, and the one that took the longest was embedding.

Export. A script streams every document out of RavenDB into one JSON file per collection: more than 70,000 words and sentences. About 50 MB.
Embed. Qdrant Cloud can embed text server-side with hosted models, and that's what the API uses for search queries in production. But hosted inference can't build a multivector from several texts on insert, so the bulk import embeds locally with all-MiniLM-L6-v2 through transformers.js. It's the same model Qdrant hosts; I checked and the vectors are identical (cosine similarity 1.0), so what I tuned locally held in the cloud. 70,000 documents took about 13 minutes on a laptop.
Upsert in batches, keeping the RavenDB UUIDs as point ids. Importing twice overwrites instead of duplicating, which makes the whole thing re-runnable.
Verify. A script checks that every exported id exists in Qdrant and compares a couple of hundred payloads per collection field by field. Zero missing, zero different.
Switch. The API picks its database from one environment variable, DB_PROVIDER. Setting it to qdrant on Heroku restarts the app on Qdrant; deleting it puts RavenDB back. Before flipping it, I re-ran the import with a --sync flag that writes only new or changed documents and deletes removed ones, so nothing written in the meantime was lost.

The code change was one abstract class, DictionaryDb, with the dozen operations above, and two implementations. The services don't know which one they're talking to.

What it looks like in production

The free cluster is a single node with 0.5 vCPU, 1 GB RAM and 4 GB disk. With 384-dimensional vectors, 70,000 points use roughly a quarter of the RAM; the payloads add about 70 MB. There's room to grow the dictionary several times over before it matters, and scalar quantization or on-disk payloads would buy more.

Measured end to end from the Heroku API, vector search takes 170–370 ms (including the server-side query embedding) and filtered keyword search 65–130 ms. Talking to the cluster directly, the same similarity search has a median of 91 ms and a p95 of 101 ms over 200 calls.

Search quality is slightly different rather than worse. For "to be unharmed", RavenDB returned a list of "to protect"; Qdrant returns "to be injured" first, then "to protect". Small models sometimes rank an opposite meaning high. For "king", "mother", "water" and the offering formulas that make up most sentence searches, the results are equivalent.

What you don't get for free

No managed backups. The JSON export from step 1 is my backup, and I plan to re-run it regularly. If the cluster disappeared tomorrow, re-importing takes 13 minutes.
No SLA, community support only. The terms let Qdrant suspend any cluster "for any reason". Free clusters also get suspended after a period of inactivity; a live app keeps it awake, but a dormant one won't.
Single node. No high availability. If you need that, the Standard tier is usage-based and starts at the point where you'd outgrow 1 GB anyway.

How to start with your migration?

If you're considering the same move: list every database call first, try the import on a local Docker Qdrant before touching the cloud, and wish you all success~

I built a Claude Code plugin that refuses to agree with me

Amro — Mon, 20 Apr 2026 21:14:42 +0000

I typed this into Claude Code the other day:

❯ claude code is better than codex

⏺ Noted.

No pushback. No "on what metric?" Just a polite nod.

That's the bug. Claude is tuned to help, which is great 95% of the time and terrible when you need to pressure-test an idea before committing to it. "What could go wrong with this?" produces a gentle bulleted list. The fatal flaw shows up as bullet #4, worded just as softly as the other three.

So I built objection — a Claude Code plugin (also works in Cursor, Codex, Windsurf via npx skills) that flips the posture. Claude becomes opposing counsel. Your idea is a claim. Your job is to defend it.

Before / After

Default Claude:

❯ claude code is better than codex

⏺ Noted.

Claude with objection:

❯ claude code is better than codex

⏺ The claim: Claude Code is better than Codex.

  Objection — missing evidence. "Better" on what axis, measured how?
  Code quality on a benchmark, latency, cost per task, tool-use
  reliability? Without a metric and a number, this is preference
  dressed as fact.

One is useful. The other is a nod.

The VERDICT

When you're done ("I'm done" or "I rest my case"), you get a shareable block:

═══════════════════════════════════════
            VERDICT
═══════════════════════════════════════

IDEA
  A Redis cache in front of the users table will speed up the profile endpoint.

OBJECTIONS
  1. Missing evidence of bottleneck — resolved
  2. Cache invalidation strategy — unresolved

RESULT: FAILED

  Strongest unresolved objection:
    "A user updates their display name and sees the old value on the
     next page load. What's the invalidation strategy, and what
     staleness is acceptable?"

═══════════════════════════════════════

Screenshot it. Paste it in the PR. Either the hole gets fixed, or it's the reason you don't ship.

The rules

One objection per turn. No stacking.
No approval on first ask. Ever.
No conceding to tone, authority, or vibes. "Trust me" and "the senior signed off" are not arguments.
Every objection is falsifiable. Missing evidence, unexamined tradeoff, unaddressed edge case, weak assumption, or ignored prior art. Pick a category or don't raise it.

Install

Claude Code:

claude plugin marketplace add AmrAnwar/objection && claude plugin install objection

Any other agent:

npx skills add https://github.com/AmrAnwar/objection

Then /objection <your claim> — or just say "challenge me", "poke holes", "devil's advocate this".

Disable when you don't want it:

claude plugin disable objection

When I use it

Not always. Claude's default mode is right for most work. I reach for objection when I'm about to write an ADR, when I've been talking myself into something for a week, or when a proposal has momentum but feels off and I can't say why.

The goal isn't to win the argument. It's to know, before you ship, whether the argument was winnable.

Repo: github.com/AmrAnwar/objection — issues and PRs welcome.

Building Extendable Generic Nestjs Controller

Amro — Fri, 14 Oct 2022 09:29:52 +0000

When I was working with the Django rest framework, there was a class called ModelViewSet, just inheriting this class and specifying your database model name, all the CRUD endpoints would be created for you automatically. I really liked this idea as it gives you consistency look to your API, less code has to be written and finally lets you focus more on the business logic.

This article will provide implementation to a generic class that when it is extended will provide similar functionality to ModelViewSet.

In order to do that TypeORM library is used, as our model library. As an example, I will do the classic Article model and will show how I will do the endpoints for it, as the model would be:



@Entity('article')
export class ArticleEntity extends BaseEntity {
  @PrimaryGeneratedColumn({ name: 'article_id' })
  articleId: number;

  @Column()
  title: string;

  @Column()
  body: string;
}

The controller of this model with a GET endpoint would be normally like this:



@Controller({ path: 'article' })
class ArticleController {
 constructor(
   @InjectRepository(ArticleEntity)
   protected readonly repository: Repository<ArticleEntity>,
  ) {}
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number):
  Promise<ArticleEntity> { 
   return this.repository.findOne({ where: { articleId: id } });
  }
}

Now we have to create an abstract generic class with a GET function, I will call it EndPointSet, and it would look like this without implementation:



abstract class EndPointSet<T extends BaseEntity> { 
  protected abstract readonly repository: Repository<T>;
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number): Promise<T> {
    // IMPLEMENTATION HERE, KEEP READING ^^
  }
}

But now we have a problem, each different model would have a different id field name, so we can not use the findOne method, luckily Typeform provides the findOneById method, which needs only the id value, not its name, so the method implementation would be:



return this.repository.findOneById(id);

And now we can inherit the EndPointSet not only in the ArticleController but any controller as follows:



@Controller({ path: 'article' })
export class ArticleController extends EndPointSet<ArticleEntity> {
  constructor(
  @InjectRepository(ArticleEntity)
     protected readonly repository: Repository<ArticleEntity>,
  ) {super();}
}

The other endpoints will be similar to what we did in the Get function, so the final class at the end would be like that:



abstract class EndPointSet<T extends BaseEntity> {
  protected abstract readonly repository: Repository<T>;
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number): Promise<T> {
    return this.repository.findOneById(id);
  }

  @Get('list')
  async list(): Promise<T[]> {
    return this.repository.find();
  }

  @Post()
  async post(@Body() dto: DeepPartial<T>): Promise<T> {
    return this.repository.save(dto);
  }

  @Delete()
  async delete(@Param('id', ParseIntPipe) id: number): Promise<void> {
    this.repository.delete(id);
  }

  @Patch(':id')
  async update(
    @Param('id', ParseIntPipe) id: number,
    @Body() dto: QueryDeepPartialEntity<T>,
  ): Promise<void> {
    this.repository.update(id, dto);
  }
}

So yeah that is it, we now made our generic controller with all the CRUD endpoints. That is it for the first part, in the next part, I will do more work on the list function, in order to do pagination, ordering, filter.. etc. So follow for more ^^.

Implementing Onion architecture in NestJS

Amro — Thu, 18 Nov 2021 10:52:44 +0000

What’s Onion architecture?

As shown in the picture, onion architecture is a way to structure the code by dividing it into domain-driven design layers. each layer can only access the layer below it throw its interfaces, and then using the dependency inversion principle each interface will be replaced with its class.

Onion Architecture leads to more maintainable applications since it emphasizes separation of concerns throughout the system.” Jeffery Palermo

Why apply Onion Architecture in NestJs projects?

NestJs is a service-side framework based on NodeJs. NestJs has many built-in features but most importantly for us now is the Dependency Injection and the possibility to add Dependency inversion which is what we need to apply the Onion Architecture.

Building simple server-side Blog:

In the rest of the article, I’ll try to explain the NestJs implementation using a simple blog project.

I’ll assume most of the article readers already know Nestjs so I’ll focus on the architecture in the code example.

Project layers in NestJs

Domain entities: in the core of our application we have the domain, according to the Domain-driven design(DDD), we should focus our implementation around our Domain and all other layers are built around it.

In our case, the Domain Entity is just the Article, so let’s do its interface:




export interface IArticle {
  id: number;
  body: string;
  title : string;
}

Repository: is the layer that participates in the Domain Entity, like getting or deleting entity object but it has to abstract away database and infrastructure details, so it’ll work with any kind of database.

so let’s build ArticleRepository:



export interface IArticleRepository {
  get(id: number): Promise<IArticle>;
  delete(id: number): Promise<void>;
  save(input: IArticle): Promise<void>;
  update(input: IArticle): Promise<IArticle>;
}

As the Repository interface most likely will have the same functions for all Entities as it should mainly perform these abstract functions, I recommend using Generics that takes the Entity type as parameter to have general Repository



export interface IRepository<T> {
  get(id: number): Promise<T>;
  delete(id: number): Promise<void>;
  save(input: T): Promise<void>;
  update(input: T): Promise<T>;
}

Service: here we implement the use cases, it participates in the Repository to get the data it needs

in our case we need a service to get an article by id and count article characters:



export interface IArticleService {
  getArticle(id: number): Promise<IArticle>;
  getArticleLength(id: number): Promise<number>;
}

Controller: for the sake of simplification I made the controller the first layer, hence NestJs is a server-side framework. But normally in literature first layer suppose to be the UI or test.

As Controller is our first layer and we won’t use it as dependencies somewhere else so no need to write an interface for it and we can implement it directly.



import { Controller, Get, Param } from '@nestjs/common';
import { IArticle } from './article.interface';
import { IArticleService } from './articleService.interface';

@Controller({ path: 'article' })
export class ArticleController {
  constructor(private readonly service: IArticleService) {}

  @Get(':id')
  async article(@Param() params): Promise<IArticle> {
    return this.service.getArticle(params.id);
  }
}

So are we done?

ofc not yet, we just wrote the interfaces but still didn’t write the actual implementation of them, and then replace the interface with the class in the run time.
In the rest of the article, I’ll implement one of the Classes(ArticleService) and the rest will be the same.

Implementing ArticleService




@Injectable()
export class ArticleService implements IArticleService {
  constructor(
private readonly repository: IRepository<IArticle>) {}

  async getArticleLength(id: number) {
    const article = await this.repository.get(id);
    return article.body.length;
  }

  getArticle(id: number) {
    return this.repository.get(id);
  }
}

must add @Injectable() so NestJs can inject it later in a class as dependency.
the class implements the interface to make sure the class has the same functions
as we see here ArticleService has dependencies like the Controller but this time its dependency is IRepository

Dependency inversion( replacing the Interface by the Class):

In the ArticleModule we can specify a string token for each class and use this token when we use the class as a dependency.

so let’s apply that with ArticleService, giving it a token in ArticleModule:



@Module({
  controllers: [ArticleController],
  providers: [
    {
      provide: 'ARTICLE_SERVICE_TOKEN',
      useClass: ArticleService,
    },
  ],
})
export class ArticleModule {}

and using this token in the Controller to get the Class in run it:




@Controller({ path: 'article' })
export class ArticleController {
  constructor(
    @Inject('ARTICLE_SERVICE_TOKEN')
    private readonly service: IArticleService,
  ) {}
  ...
}

Note: as strings are bound to errors, it’s best practice to assign the token string to a const variable and export it from the IArticleService file and then use it instead of the string directly:



export const ARTICLE_SERVICE_TOKEN = 'ARTICLE_SERVICE_TOKEN';

export interface IArticleService {
  getArticle(id: number): Promise<IArticle>;
  getArticleLength(id: number): Promise<number>;
}

— that’s it 🎉 now imagine if we needed to change any class, we’ll just add the new class to the useClass parameter in the Module without having to change the controller implementation.

Don’t be so radical about it:

In the end, Onion architecture was made to make the development process easier, so don’t try to force it everywhere where it does not make much sense due to some libraries limitation or other reasons.

Thanks for writing till the end and wish we meet in another article. take care!