Pinecone Open-Sources AWS Reference Architecture with Pulumi | Hacker News Reader

Pinecone Open-Sources AWS Reference Architecture with Pulumi

pinecone.io

73 pointszackproser49 comments

The massive (and contextually irrelevant) AI generated images every other paragraph remind me of setting line spacing to 2.2 in order to hit the minimum number of pages for your school essay.

Thanks for the feedback!

The massive paragraph heading size compared to the text itself doesn't do the readability a whole lot of good, either.

Most of the text felt AI generated as well.

Interesting! I can assure you none of the text was auto-generated. I've written before about how I don't like having text generated for me.

I do use Grammarly for editing assistance when I'm writing something for work.

Appreciated, but 16+ MB of images - there was no need given ~4K of text. That's a 4,000 times bloat. Please, professional devs don't need this. Just give us the info.

I appreciate the feedback, but we may need to agree to disagree on this one :)

As a professional dev, I enjoy articles with eye candy and AI-generated images, especially those with a pixel-art bent make me happy.

Except for the first image which is a human-made schematic, the rest of the images are filler and serve almost 0 purpose.

At the very least they should have been sized down to 30% of their size and have the text flow around it instead of putting so many full-width images.

Images like this can be used to break up content, but the ratio is way off.

Also, the images are not full width to the content, so it creates a zig-zag noise issue when reading down the page. I would left align them, or make them full width. The images should be used to break up logical sections, but in this case they truly just look scattered randomly and just cause frustration. There is really not enough text to warrant this many (unrelated) images.

The images themselves are cool though. Kinda reminds me of the way that baby snakes are more dangerous than older ones - they are not sure how to regulate their venom so they end up using too much and it is more lethal. Save some of these images for your next blog posts =) Don't shoot them all off at once.

Professional dev does not help here. These pictures are irrelevant anyway, and an eye sore at the same time.

I do want code examples with the pretty dark syntax highlighting though

Don't forget to bump up those page margins.

They are the new cat images, borat jokes and rick rolling.

The isometric architecture diagram is hard to read as well.

Other day i was trying out Azure SQL for storing vector DB. After a POC i was able to get results on sub 1 second to get the results with 2 core serverless instance. It begs me to reconsider does dedicated Vector db really worth it ? Here is the article on how to store and query vector data https://devblogs.microsoft.com/azure-sql/vector-similarity-s...

Ask yourself the same question about an OLAP system. Once you’re at a large enough scale, it makes sense to use tools custom designed for your access patterns.

I work on Azure SQL, but it’s pretty clear that this is a cool demo. It may scale for some usages, but I wouldn’t build a production system on it.

Well tried it with ~ 34 million records , which is good enough sample for our usecase

At what number of queries per second?

> Azure SQL

> large enough scale

You mean something like the Hyperscale service tier? This is what we are building our new products on top of.

Hyperscale is awesome. My point is more for vector search. Once you’re at a large enough scale, the simple algorithms for similarity search break down. You’d need something that implements HNSW and designed their database indexes around it.

>After a POC i was able to get results on sub 1 second to get the results with 2 core serverless instance

Is that good or bad?

~ 34 million embeddings , Seems this is a good enough sample for our use case.

The article says you had 500ms latency while searching through only 25k records. Presumably at 1 query at a time? That's probably 2 orders of magnitude slower than a vector database.

Now THAT is developer advocacy-- a reference architecture and a complete video series. I'm intrigued by the fact that Typescript was chosen for this work. Are you finding that clients are rolling out ML architectures based on Typescript microservices?

Thanks so much for your support

We are finding that JavaScript is an often overlooked language for working in AI:

https://www.pinecone.io/learn/javascript-ai/

There's also a very nice synergy between using a language like JavaScript (many are familiar enough to read through and understand what's happening) and the type safety that TypeScript introduces.

We are seeing a lot of interest in working with Typescript hence why many of our examples are TypeScript applications.

Pinecone’s aggressive marketing here on HN is getting really old.

As someone interested in kicking the tires of VectorDBs, where does Pinecone rank? Is there one that will be "future proof"?

Redis is probably better suited

I work for Pinecone so my bias is obvious, but objectively: Pinecone is ranked as the most popular vector DB according to multiple sources [1][2][3][4], the best funded ($100M Series B), and is used in production by the likes of Shopify, Gong, Plaid, Zapier, Midjourney, CVS, and thousands of others.

[1] https://retool.com/reports/state-of-ai-2023

[2] https://state-of-llm.streamlit.app/#third

[3] https://db-engines.com/en/ranking/vector+dbms

[4] https://www.g2.com/categories/vector-database

Couple relatively recent HN threads that give a good overview of the vector database landscape.

https://news.ycombinator.com/item?id=36943318

https://news.ycombinator.com/item?id=38416994

https://news.ycombinator.com/item?id=38420554

Regarding "future-proof-ness": we've been building production-grade vector search since 2018 and have a number of organizations running it at billion+ scale in production environments. It's all open source too.

https://milvus.io

Sounds silly to go to a vector DB vendor to get reference architecture for my app where it will only be a small part of my app.

I believe the point is that you can leverage the reference architecture for that small part of your app.

Yes - this and to make it easier to understand how you'd use Pinecone at scale.

We get a lot of feedback that our many open-source Jupyter notebooks (github.com/pinecone-io/examples) are very helpful for learning new techniques and understanding how patterns work - even for starting new applications.

However, we're also often asked how to go from Notebook to prod. The Reference Architecture is a step in the direction of making this easier and more clear.

Why is this on the main page? Just a few paragraphs of text with autogenerated images, and the contents feels like LLM-generated, too.

Thanks for your question!

The images were generated via DALL-E - so they're not technically "autogenerated". They were created using a generative model, however.

The content itself definitely was not generated by an LLM - although that feels like a low-effort comment =/ What in particular felt LLM-generated to you?

I think this is on the main page because being able to set 3 environment variables and run `pulumi up` to get to a production-ready system in your own AWS account, without having to purchase anything, is a massive time-saver for anyone with a high-scale use cases that wants to use Pinecone's vector database.

Anyone have good experience with Pulumi? The IaC space feels a bit crowded

I've worked with Terraform extensively, including doing a lot of similar work (Reference Architectures, modules, AWS) over the past several years.

This was my first time using Pulumi, and it was very much a delight. There's clearly been a lot of thought and effort put into the plugins and overall developer experience.

For example, you can have Pulumi handle the Docker image builds for you - as well as the ECR repository logins and pushes. This means that your end users don't need to manually build images, log into ECR and push them - they just run `pulumi up` instead.

My setup extends on this: the pulumi stack creates ECR repo, IAM user+access token, adds credentials and ECR details to GitHub actions secrets, and GitHub actions builds tags and pushes the images to ECR when a release is (automatically) tagged.

Pulumi is (mostly) a bliss!

I've used Pulumi for professional projects and personal projects, and I think it's fantastic. You can write your code in pretty much any major language (professionally, i use Python, personally I use Go), and you get the same output. Running the Pulumi program itself couldn't be simpler.

My one critique is sort of weird in the sense that Pulumi supports way more than its public documentation says. I hope they up their documentation game in the future, because there are a lot of things that I had to go digging through source code to find out how to implement. But that's really a minor nitpick in the grand scheme of things. Big Pulumi fan here.

I agree! Looking at the source code is invaluable. Also if you use Azure, look at the generated ARM templates, for clues on how to set things up where the docs are short on details. It is nice they don't abstract over the ARM templates too much.

Pulumi docs engineer here. Really appreciate that feedback -- what sort of thing did you have to go digging for? We're definitely investing here so I'd love to hear more about what you were looking for and didn't find (or what you discovered along the way that we could've made clearer). Thanks!

There are more than a few resource types lacking import examples/details in the docs.

Other than that, for most resources I use the docs are pretty good.

Yep, this, exactly.

It's been a few months, so I can't remember details, but one thing I wanted to use some features was the EventBridge Scheduler and a few other things like that, and I couldn't find anything on the website that referenced those, but I did find the relevant classes defined in the code and was able to get everything working within a few minutes. (Kudos to the comments around the code!)

Yes Pulumi is nice. Having the power of Typescript types (if you choose Typescript) is amazing.

The thing is I haven't used Terraform extensively so I can't compare.

The main downsides I found are probably IaC downsides in general. Such as scenarios where you need to click-ops to repair because only some of the infra was deployed. I think the clouds need to make their stuff IaC friendly to avoid this though.

My main fear is taking on that dependency on something newer. With Terraform if the company goes bust, the community could take over, and probably it would become an Apache project. Maybe Pulumi would too. It is not good enough for it to be open source. It needs to keep up with the daily changes in the cloud.

Strong agree here - I am still keeping an open mind about TypeScript - using it for frontend / Vercel web apps and while maintaining open-source examples.

I will say it was very nice getting the type hints for infrastructure while developing as well as hints about something being unused, etc.

It overall worked better than I was probably expecting.

Also agree with your points on the pain of IaC - it's terrific when it works but there's always those special "except this resource doesn't follow any of those rules" cases to make things painful and extra complex.

I've also found that IaC can have a chilling effect for folks who haven't ever tried it before - it's a powerful abstraction tool - but at the end of the day you also need some level of understanding around what is happening under the hood - where to debug an error (which level), etc.

For a previous startup a couple of years ago I tried to get our infra onboarded with terraform, hit a bunch of blockers, switched to Pulumi, and have used it for every project big or small since.

Hits a really nice sweet spot for me -- yes, you want your infra definition to be declarative, but being able to write real code in a real language (Typescript in my case) that generates that declarative infra definition is exactly the right level of abstraction imho.

This very much gels with my own experience.

It was my first time working with Pulumi and despite not being sure yet how I truly feel about TypeScript - it was a pleasant experience to be able to use programming constructs I'm already familiar with.

I think that's the real leg up that Pulumi has on Terraform.

With HCL / Terraform - you're supposed to be dealing with configuration, but - we also need loops and maps - so we sort of get a mix between a configuration language and a programming language.

As soon as you need to do something even moderately complex you're in a world of pain (automatically deploying and validating Route 53 records via DNS in AWS, I'm looking at you...).

Reply on news.ycombinator.com