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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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!
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!)
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.
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.
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.
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...).
