AdminAndrew Davidson
(VP, Cloud Products, MongoDB)
My feedback
180 results found
-
2 votes
An error occurred while saving the comment -
7 votes
We recently released tags on database deployments. You can apply tags to new or existing clusters or serverless instances.
https://www.mongodb.com/docs/atlas/tags/
We are planning to have these tags displayed in billing Invoices and we'd love to hear more from you. Reach out to me if you'd like to provide additional feedback about this feature request.
An error occurred while saving the comment We definitely look forward to building a better way to manage billing contexts in the future, likely involving tagging, as well as to making Atlas cluster tags more visible within the UI in some capacity in the future. We are working on a number of other priorities right now so this will not be something we'll see for a while, unfortunately.
-Andrew
-
47 votes
An error occurred while saving the comment Hear you there: we are working on designing a very different higher level of abstraction offering that aims to deliver to what you want here. This is going to take time but definitely appreciate the feedback.
-Andrew
An error occurred while saving the comment Hi Babak,
One of the challenges is that it's significantly more expensive to opt into Provisioned IOPS even when not using too many of them -- Can you confirm whether you would be comfortable using Provisioned IOPS all the time (there is a significant premium cost to doing so) in order to leverage auto-scaling for IOPS?
Further, what kinds of indicators for your workload would you see as canonical drivers of needing to scale IOPS? We want to learn from you since this is nuanced and difficult to get right.
-Andrew
-
23 votes
An error occurred while saving the comment Hi Martel,
One option available today is configure identity federation (https://docs.atlas.mongodb.com/security/federated-authentication/) and then use the auditing that your IdP offers.
Note that Atlas audits any material action taken within the MongoDB Cloud UI (cluster configuration changes, security configuration changes, data explorer usage, etc).
-Andrew
-
21 votes
An error occurred while saving the comment It is possible to use the generic Webhooks endpoint to push to ServiceNow: We are working to get a tutorial documented.
-Andrew
-
35 votes
An error occurred while saving the comment Hi Neelakantan,
Have you seen both the data explorer (found under the "Collections" button on the Atlas cluster) which offers a query browser and aggregation pipeline builder, and MongoDB Charts which offers beautiful native visualizations on top of data in your MongoDB Atlas clusters?
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Colin,
Thanks for flagging: we hear you loud and clear here and will be working on this in a few months, after we complete some projects in flight. We'll be mindful to ensure that we don't break programmatic users of our APIs when making this change.
-Andrew
-
1 vote
An error occurred while saving the comment Hi Shaun,
Have you looked into enabling Atlas cluster auto-scaling? This will allow you to rely on Atlas' built in algorithm for doing this scaling, which will take into account whether downscaling is appropriate. Learn more here: https://docs.atlas.mongodb.com/cluster-autoscaling/
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Jan,
The great thing about aggregations is that you're pushing down to the database engine to do the heavy lifting. However where you wish to have workload isolation so that your operational workload is not fighting for resources with your analytical/heavy aggregations, we recommend you explore Atlas Analytics Nodes -- these are special replicas that you target for isolated queries using a read preference tag. Learn more here: https://docs.atlas.mongodb.com/workload-isolation/#analytics-nodes-for-workload-isolation
Cheers
-Andrew -
2 votes
An error occurred while saving the comment Hi Krishna,
Is it possible that you did not open up the inbound network access from the MongoDB Atlas Live Migration service to the secondary node that your cluster failed over to?
-Andrew
-
164 votes
Hi all – We are currently developing collection and database-level restores. We expect this feature to be released in CY2025, but will update here once it is launched.
An error occurred while saving the comment Hi Thirumalaisamy,
We have some guidelines in the green box on this docs page that describe how to speed up a backup restore:
https://docs.atlas.mongodb.com/backup/cloud-backup/restore/#restore-your-snapshot-to-an-atlas-clusterI am going to get this updated to be even more precise: For the fastest possible restore, restore to a cluster in the same Atlas Project, in the same region, with the exact same storage size as that of the cluster the Cloud Backup snapshot was taken from.
If you do this, you will have the fastest possible restore (irrespective of data size) -- from there you can very easily remove any collections/databases you don't need.
Cheers
-AndrewAn error occurred while saving the comment Hi Thirumalaisamy,
One option is to simply restore the full backup and then cull everything you don't need -- this can all be driven programmatically. Can you share whether this would work for you?
Cheers
-Andrew -
11 votes
An error occurred while saving the comment Hi Kyle,
While we do not plan to introduce a greater than 72 hours heads up, you can always defer maintenance for a week up to two times. You can also select your preferred hour of the week for our heads up to go out 72 hours. If Monday is sub-optimal, why not move your window back int he week? This gives you the power to decide when the optimal time for you is.
-Andrew
An error occurred while saving the comment Hi Kyle,
Thanks for reaching out: importantly, Atlas maintenance is performed in a rolling manner and should only manifest as a replica-set level election from a client perspective. This means that an application with built-in retry logic (MongoDB offers retryable writes and retryable reads since 4.2) generally need not worry about maintenance.
We have the "Test Failover" capability in the cluster's "..." menu in the Atlas UI for testing your resilience posture.
We introduced maintenance windows so that our customers that are less election-tolerant could have more control into the preferred time the maintenance would occur. You should not need to schedule downtime with your end customers, and if maintenance is causing you downtime we would like to provide you assistance to ensure there isn't a driver bug at play.
-Andrew
-
6 votes
An error occurred while saving the comment Hi AYMERIC,
Being transparent with you, it would be a massive architectural change to contemplate something like this and as a result not something that is going to happen any time soon.
However, slightly orthogonal but hopefully directionally helpful: we are looking at making it possible to use a smaller CIDR for the Atlas-side VPC at the Project-level on GCP in the future. The reason we use a wide CIDR on GCP is that GCP VPCs are global (an awesome feature) and we wanted to leave headroom for you to grow into any region over time. However in practice we realize there's a middle ground compromise here to be found.
-Andrew
-
42 votes
An error occurred while saving the comment Hi Greg, Can you comment on whether the new Cross-Org Billing capability I mentioned earlier may suffice for your needs? It allows you to use multiple Organizations for different groups to isolate authorization but still share a billing subscription.
Cheers
-AndrewAn error occurred while saving the comment Hi Michael,
We hear you loud and clear on needing to have more flexibility and have long term plans to do so.
Importantly, we also just released a new capability for Atlas customers on annual subscriptions: Cross-Org Billing. With Cross-Org Billing you can link other Atlas Orgs to your "Paying Atlas Org" and have them pay through that subscription.
One of the key drivers for creating this was to give customers more flexibility so that they can have authorization-level isolation across different Orgs, while maintaining a loose coupling for a shared Billing environment. By the way, you can move Projects between Orgs if you're an Org Owner of both orgs -- doing so is a no-downtime purely logical/mapping change. This might allow you to give folks their own Org and then from there they can set up their own Teams/Projects as they wish?
More detail here: https://docs.atlas.mongodb.com/billing/#cross-organization-billing
Cheers
-Andrew -
456 votes
An error occurred while saving the comment Hi Greg,
We do plan to enable a database user to be granted multiple custom roles in the future. This remains a number of quarters out, however. Apologies for the friction in the meantime. Note that this particular suggestion was originally scoped to the slightly orthogonal context of the MongoDB Cloud control plane users (e.g. instead of database users).
Addressing Kico's original intent, note that annual subscription customers can now take advantage of Cross-Organization billing (see docs https://docs.atlas.mongodb.com/billing/#cross-organization-billing) which allows you to more easily use distinct Organizations for authorization-level isolation while maintaining a loose coupling for billing centralization. I think this will open up a degree of flexibility that was previously lacking in our control plane authorization experience.
Nevertheless, we hear you loud and clear on wanting to be able to express finer grained control plane privileged actions and roles, and do plan to address this over the long term.
Cheers
-AndrewAn error occurred while saving the comment Hi Michael,
Thanks for flagging all of issues: we definitely want to improve on all of them.
You may want to take advantage of new functionality that we just launched for annual subscription customers: Cross-Org Billing. See https://docs.atlas.mongodb.com/billing/#cross-organization-billing for more information.
With this capability you can move some Projects to other Organizations (this can be done without downtime via a purely logical backend move), giving you a loose-coupling with authorization-level isolation, but a shared billing subscription. Organization-scoped users can only see the billing usage associated with their respective Organization.
Cheers
-Andrew -
1 vote
An error occurred while saving the comment (I ask because in our upcoming MongoDB 4.4 we will have an exciting new capability coming to MongoDB Atlas that I think will be very compelling to you)
An error occurred while saving the comment Hi Daniel,
Can you clarify what you mean: are you looking to authenticate a Lambda function directly to a MongoDB Atlas cluster using AWS IAM for authentication?
Cheers
-Andrew -
25 votes
An error occurred while saving the comment Hi Sylvain,
You may want to take advantage of new functionality that we just launched for annual subscription customers: Cross-Org Billing. See https://docs.atlas.mongodb.com/billing/#cross-organization-billing for more information.
With this capability you can move some Projects to other Organizations (this can be done without downtime via a purely logical backend move), giving you a loose-coupling with authorization-level isolation, but a shared billing subscription.
Cheers
-Andrew -
12 votes
An error occurred while saving the comment Hi Kaz,
Out of curiosity, did you experience an accidental pause of a production system? One thing we do for termination is require the user to type in the cluster name--that could be something we'd do here but hadn't seen it as quite necessary since Pause is a reversible operation and so we instead protect it with an informational modal and large red button. Knowing that this has not been enough is a valuable data point.
-Andrew
-
27 votes
An error occurred while saving the comment Hi Matthew,
It would be helpful to understand what it is about your application that would benefit from. this. Noting that cross-AZ network hops are generally sub-2ms, single-AZ network affinity is usually reserved for the kinds of applications with more niche latency requirements (where latency trumps availability) like ad serving and high frequency trading.
It would help to understand how you would take advantage of this, what it would mean for your applications, etc. Would you have other application tier instances running in the other AZ in the event of failure of the "preferred" AZ? Maintenance is another consideration--one key benefit of not thinking at the AZ level is you avoid pets and force yourself to be resilient for failures and maintenance.
Thanks
-Andrew -
1 vote
An error occurred while saving the comment Hi Ben,
You can open a help request any time using the lower-right in-UI chat bubble. This service is included for all Atlas customers.
-Andrew
Hi Connell,
Being intellectually honest with you, bringing a true SaaS-style experience to Azure Stack, Google Anthos, or AWS Outposts that compares with Atlas is unfortunately a very large undertaking.
However, where you cannot take advantage of a pure-play public cloud region on one of the big three, we do offer an alternative: MongoDB Cloud Manager offers software that helps you monitor, automate, and backup your self-managed MongoDB databases https://www.mongodb.com/cloud/cloud-manager While Cloud Manager certainly does require more work for you than Atlas, it at least offers that true flexibility you're seeking for when you need to reach regions that Atlas cannot yet reach. You can use our Kubernetes operator in this model by the way, which at least offers a standard orchestration tie-in for non-public cloud contexts.
-Andrew